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Since the appearance of Local Area Networks (LANs), their use and bandwidth 
consumption have increased considerably. Users are now seeking new technologies to 
satisfy their bandwidth demand. Many consider ATM as the solution to their needs. Though 
ATM is fairly new networking technology, it has made several strides, and is now considered 
a viable technology that is applicable in a LAN environment. However, migrating from 
today’s shared-medium LANs (Token-Ring and Ethernet) to an ATM LAN exposes an 
organization to difficulties, risks, and costs. A well-thoughtout migration strategy reduces 
the impact of these factors while implementing ATM technology. 

This study reviews ATM technology and its application in a LAN environment, 
evaluates the Systems Management Department Computer Lab LAN, redesign the LAN 
using ATM technology, and develops an evolutionary strategy to implement the proposed 
ATM LAN. 
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I. INTRODUCTION 



A. BACKGROUND 

Since the appearance of Local Area Networks (LANs), their use and bandwidth 
consumption have increased considerably. As more users access the LANs, and their 
applications capability (text, graphics, and video intensity) increases, higher bandwidth will 
be required. No longer is the "normal" 10 or 16 megabits per second (Mbps) pipes the 
typical option when installing new LANs or upgrading existing ones. Users are now 
asking for substantial increases in bandwidth to meet their application-intensive bandwidth 
requirements, and to allow multiple simultaneous access to the pipes. 

New technologies have emerged to satisfy this demand for bandwidth. They 
include Fast Ethernet (100 Mbps), Fiber Distributed Data Interface (FDDI), and 
Asynchronous Transfer Mode (ATM). 

Cost is a major driving factor in deciding to adapt new LAN technology. User will 
always pose the question, how much will it cost to install the new technology? In the case 
of ATM, users are also asking themselves, do I want to be the first to implement an ATM 
network, and what are my risks? 

ATM has made several strides, and is now considered as a viable technology that is 
applicable in the LAN environment. Although ATM was originally developed as an 
international standard for Synchronous Optical Network (SONET)-based Wide Area 
Networks (WANs), its attractiveness for LANs has resulted in ATM LANs appearing well 
in advanced of long-haul ATM services. The Army High-Performance Computer 
Research Center performed experiments in 1993 to evaluate the capability of ATM 
satisfying the communications needs of distributed networking computing. The results 
revealed that network computing is very promising over Local ATM Networks. 

B. PURPOSE 

The purpose of this thesis is to redesign the Systems Management (SM) 
Department's computer lab LANs using ATM technology. The research entails reviewing 
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ATM technology, assessing the existing computer lab LANs, redesigning the lab LANs, 
and devising a strategy to upgrade the current LANs to an Local ATM Network. 

C. SCOPE AND METHODOLOGY 

The main focus of this research is to review ATM technology and its possible use 
in a LAN environment; perform an in depth study of the existing SM Department 
computer lab LANs in Ingersoll IN- 158, IN-224, and IN-250; redesign the current lab 
network; and the development of an evolutionary strategy to implement the proposed 
ATM LAN. 

The research will entail a review of current books, periodicals and news articles on 
LANs, ATM technology, and Local ATM Networks. Academic and professional 
specialists will also be interviewed. These specialists will have been involved in the de- 
velopment of LANs and WANs, and have an understanding of the ATM technology. My 
emphasis will be on hardware and software required to implement the Local ATM 
Network, and the hardware and software compatibility issues that may occur when 
running existing applications on a Local ATM Network. 

D. ORGANIZATION OF STUDY 

Before delving into converting an existing LAN to a Local ATM Network, one 
should have a clear understanding of ATM, its application in a local environment, and 
implementation issues associated with ATM. Because these areas will play a crucial part 
in upgrading the SM computer lab LANs, I have devoted Chapters II and m to these 
topics. The remaining chapters cover an assessment of the SM lab LANs, the application 
of ATM technology to the LANs, and a migration strategy to convert or upgrade the SM 
lab LANs to an ATM LAN. The final chapter provides a conclusion of my research. 
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H. ASYNCHRONOUS TRANSFER MODE (ATM) TECHNOLOGY 



A. INTRODUCTION 

1. Purpose of Chapter 

The purpose of this chapter is to provide a basic concept of ATM. An overview of 
ATM's functionality is given, and standardization issues are discussed. The information 
presented in this chapter gives a general understanding of ATM. In-depth information can 
be obtained in the resources provided in the List of References and the Bibliography. 

2. Evolution of ATM 

To better understand the evolution of ATM, a brief look at pre-ATM technologies 
(circuit switching, packet switching, and frame relay) is required. These technologies are 
in use today. However, as user requirements have increased, so has the need to transfer 
information in faster and more efficient modes. New applications are being implemented 
which require higher bandwidth, better quality of services, and the new transfer mode 
(ATM). Some applications functions properly using older and slower technologies. 

a. Circuit Switching 

Circuit switching is a transfer technology that has been used in the 
telephone system since the advent of telephones. The Plain Old Telephone System 
(POTS) uses circuit switching technology. POTS establishes a circuit, path, or connection 
to set up the call and maintains the connection for the duration of the call. However, both 
parties must be available at their respective node to establish the connection. The path 
terminates when one of the users breaks the connection by "hanging up" the receiver. 

Though circuit switching was originally designed for telephone 
communications, it has found tremendous use in data transfer. Many users use this 
transfer mode for traffic that is time sensitive, has a constant bit rate, and regular 
transmission intervals. 
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Circuit switching has two primary advantages. It is transparent, in that 
once the connection is made, no additional processing is required by the sending or 
receiving units. The second advantage is that during the data transfer phase, routing, flow 
control, and error control are avoided. This allows for simplicity in software. (Stallings, 
W., 1992, p. 28) 

A key disadvantage of circuit switching is the inefficient use of lines 
(trunks). Once the circuit is established, the line is not available for other users. These 
users receive a busy signal when trying to access the line. 

b. Packet Switching 

Packet switching transfer mode partially evolved as a result of the 
inefficient use of lines in circuit switching. As users discovered the advantages of 
transmitting information over telephone lines, data communications grew tremendously. 
The circuit switching technology alone could not efficiently meet the growing bandwidth 
demand. Telecommunications experts invented a transfer mode (packet switching) that 
allowed the sharing of bandwidth and included store and forward schemes to 
accommodate congestion or busy signals between nodes. 

Packet switching uses a method known as packetizing to disassemble 
messages into multiple packets. Each packet contains a header for addressing, and error 
control. The header information allows the packets to take various paths to reach their 
destination. At the destination, the packets are sequenced, depacketized, and the message 
is reformatted to be readable by the receivers). 

The disassembly and reassembly of the message requires more time. As a 
result, this transfer method is not efficient for the transmission of time sensitive 
information (voice and video). However, it does allow the use of shared bandwidth 
(packets taking various path to reach the destination). This makes packet switching 
suitable for bursty traffic such as data. 
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c. Frame Relay 

Frame relay is a form of fast packet switching and its concepts are similar 
to "regular" packet switching. However, frame relay uses faster transmission facilities. 
No addressing, flow control, or error control is used. The data is packetized into variable 
sizes. Before any data is transmitted, a connection is established, a permanent virtual 
circuit is created, and all the packets travel along this one path to the destination. There is 
no need for sequencing because the packets arrive at the destination in the same order that 
they left the origin. Once all the packets have reached the destination, the circuit is 
terminated and is available for use by other parties. 

d. ATM 

ATM (also called cell relay) is another form of fast packet switching. 
Unlike other switching technologies, ATM relay uses fixed sized packets instead of 
variable sized packets. ATM takes the advantages of circuit switching and packet 
switching, and combines them to maximize efficiency, transmission speed, and throughput 
(Luce, C. A., 1994, p. 26). Circuit switching establishes permanent circuits before data is 
transmitted. ATM sets up virtual circuits using virtual path identifiers and virtual channel 
identifiers. These circuits remain intact for the duration of the connection and each cell 
uses this path to reach the destination. Similar to frame relay, where the bandwidth is 
shared, other users can use the virtual path when it is idle and awaiting a response from 
either the sender or the receiver which established the path originally. 

3. Driving Factors behind ATM 

ATM is an emerging technology as a result of four factors (ATM Forum, 1994). 
First, ATM has grown out of a need for a worldwide standard to allow interoperability of 
information, regardless of the "end-system" or type of information. It is driven by 
international consensus instead of one particular manufacturer, or a group of vendors. 
Second, ATM is a technology that can be used in a LAN, metropolitan area network 
(MAN), backbone network (BN), or WAN environment. As users requirements to expand 
from a LAN to a WAN, even globally, ATM can be used to accommodate the users' 
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needs, and the users networking capabilities will not be the limiting factors. Third, ATM 
supports various types of information (voice, data, video). It is the only standard 
designed to support the simultaneous transmission of voice, data, and video, as shown in 
Figure 2. 1 . Lastly, ATM allows for the transmission of information at various speeds, 
ranging from a few Mbps to several gigabits per second (Gbps). 




Figure 2:1 ATM System Architecture (ATM Forum, 1994) 



4. Benefits of ATM 

Along with the ability to simultaneously transmit voice, data, and video, ATM has 
several other key benefits that makes it appealing to users. These benefits, discussed 
below, also contribute to ATM's capability and power. 

a. Simplification of Network Management 

Because ATM can span from a LAN to a WAN, it simplifies network 
management. Network managers can be trained on one set of tools or technology to 
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manage an ATM LAN, MAN, BN, or WAN. As a result training time and cost are 
reduced. 



b. Compatibility with Current Cable Plant 

ATM is not designed for a specific type of physical transport. It can be 
transported over twisted pair, coax, and fiber. This makes it compatible with existing 
network cabling plant, thereby alleviating the need to replace existing cabling with ATM 
congruous cabling. There are some unresolved issues regarding ATM use over satellites. 
These issues pertain to the effect of satellite delays on data and the issues of congestion 
control and error correction required for reliable transfer of data (ATM Forum, 1994). 

c. Incremental Migration Capability 

In order to use ATM in an existing network, one does not have to wait 
until the entire network has been upgraded to an ATM network. Instead, one can gain the 
benefits of ATM incrementally by upgrading portions of the network based on new 
application requirements and business needs. 

d. Long Architectural Lifetime 

ATM is designed to be flexible and scaleable in geographic distance, the 
number of users, and access and trunk bandwidths. ATM can be used locally, in a 
metropolitan area, transcontinentally, or even globally. The maximum number of ATM 
user addresses far exceeds FDDI's (500 for one ring, 1,000 for both rings). As mentioned 
earlier, ATM speeds are flexible. They can range from a few Mbps to several Gbps. 

B. ATM PRINCIPLES 

This section provides a general overview of ATM and how it works. 

1. ATM Cell 

As mentioned in the previous section, ATM uses fixed length cells. Figure 2.2 
depicts a generic view of the cell format; each cell contain 53 bytes; the first five bytes 
consist of header information, and the remaining 48 bytes is data. The primary function of 
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the header is to act as the addressing mechanism. The data field holds the actual 
information. 



Header 


Data 


5 Bytes 


48 Bytes 



Figure 2.2 ATM Cell Format 



Figure 2.3 provides a detail format of the ATM cell. The header section comprises 
of GFC, VPI, VCI, PTI, CLP, and HEC. The VPI, VCI, CLP, and HEC will be discussed 
in depth later. The GFC is used for user network interface (UNI), workstation- 
to-ATM-switch connections. The GFC does not exist in network-network interface 
(NNI), ATM-switch-to-ATM-switch connections. A larger VPI field is used for trunking 
in NNI connections. 
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5 Bytes 



4 

48 Bytes 

I 



1 Byte 



GFC/VPI 


VPI 


VPI 






VCI 




« . 


PTI 


CLP 


HEC 


Cell 

Payload 



GFC - Generic Flow Control 
VPI - Virtual Path Identifier 
VCI - Virtual Channel Identifier 
PTI - Payload Type Identifier 
CLP - Cell Loss Priority 
HEC - Header Error Control 



Figure 2.3 Detail ATM Cell Format 
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2. ATM and the Open System Interconnection (OSI) Model 

The OSI model is used with tremendous success to model communication systems. 
The same logical hierarchical architecture used in OSI is used for the ATM Broadband 
Integrated Service Data Network (B-ISDN) network (de Prycker, M., 1993, p. 111). 
Figure 2.4 shows the ATM hierarchy and the OSI model (Luce, C. A., 1994, p. 30). The 
ATM physical layer is similar to the physical layer of the OSI model. The ATM layer can 
be considered as equivalent to the data link layer of the OSI model. The ATM adaptation 
layer also performs functions of both the data link layer; it is capable of performing a few 
functions of the presentation, session, transport, and the network layers. Figure 2.5, on 
the following page, illustrates ATM in a layered architectured fashion, and provides a 
general depiction of how ATM works. Subsections 3, 4, and 5 discuss the Physical Layer, 
the ATM Layer, and the ATM Adaptation Layer. 



ATM B-ISDN Protocol Layers 


OSI ISO Reference Model 


Application Layer 




Application Layer 


Higher Layer 




Presentation, 

Session, 


ATM Adaption Layer (AAL) 
Convergence Sublayer 




Transport/ 
Network Layers 


Segmentation & Reassembly 
Sublayer 






ATM Layer 




Data Link Layer 


Physical Layer 
Transmission Convergence 
Sublayer and Physical 
Medium Dependent 
Sublayer 




Physical Layer 







Figure 2.4 ATM/B-ISDN Model and OSI Model 
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Figure 2.5 ATM Layered Architecture 



3. ATM Physical Layer 
a. Sublayers 

The physical layer contains two sublayers: the Physical Medium (PM) 
sublayer and the Transmission Convergence (TC) sublayer. The PM supports pure 
medium dependent bit functions. It is responsible for the correct transmission and 
reception of bits on the appropriate physical medium. The TC converts the ATM cell 
stream into bits to be transported over the physical medium. This sublayer performs five 
functions (de Prycker, M., 1993, p. 113): 

♦ Cell rate decoupling to adapt rate of valid ATM cells to the payload capacity of 
the system. 

♦ Generation of the HEC syndrome of each cell at the transmitter, and its 
verification at the receiver. 

♦ Cell delineation to allow for recovery of cells at the destination. 

♦ Transmission frame adaptation. 

♦ Generation and recovery of transmission frames. 
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b. 



Error Control 



ATM uses no link-by-link error control. The two end nodes on any 
connection provide the control at the physical layer (Luce, C. A., 1994, p. 31). The 
header designates eight bits for error detection and error correction. The receiver has a 
correction mode and a detection mode. In the correction mode, cells with a single bit 
error are corrected. In the detection mode, cells with two or more bit error are discarded, 
and require retransmission. Figure 2.6 depicts how error correction is performed at the 
receiver (de Prycker, M., 1993, p. 123). 




4. ATM Layer 

The ATM Layer is completely independent of the physical medium used to 
transport ATM cells. As a result, it is also fully independent of the physical layer. The 
ATM layer performs the following main functions (de Prycker, M. 1993, p. 115): 

♦ Multiplexing and demultiplexing of cells of different connections (identified by 
different VCI and/or VPI values) into a single cell stream on the physical layer. 

♦ Translating the cell identifier, which is required in most cases when switching a 
cell from one physical link to another, in an ATM switch or cross connect. 
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♦ Providing the user a virtual channel connection or virtual path connection with 
one quality of service class, out of a number of classes supported by the 
network. 

♦ Managing layer types using information in the cell header. 

♦ Extracting (adding) the cell header before (after) the cell is delivered to (from) 
the adaptation layer. 

♦ Implementing a flow control mechanism on the user-network interface. 

5. ATM Adaptation Layer 

The ATM Adaptation Layer (AAL) enhances the services provided by the ATM 
layer to a level required by the next higher layer. It is subdivided into two sublayers: the 
segmentation and reassembly sublayer (SAR), and the convergence sublayer (CS). The 
primary function of the SAR sublayer is segmentation of the higher layer information into a 
size suitable for the payload of the consecutive ATM cells of a virtual connection, and the 
inverse operation, reassembly of the contents of the cells of virtual connection into data 
units to be delivered to the higher layer. The convergence sublayer performs functions like 
message identification, time/clock recovery, etc. (de Prycker, 1993, p. 115) 

The AAL provides the user the capability to send various types of information over 
an ATM network at either constant or variable bit rates. The end-to-end connection 
established to transport the information can be connection or connectionless oriented. The 
information can be either voice, data, video, image, or even a combination of these in 
multi-media applications. The below table provides the classes of services offered and the 
protocol support by ATM B-ISDN. 
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Class: 


A 


B 


C 


D 

I 


Example 


Voice/Video 


Packet Video 


Data (IP, X.25) 


Data (SMDS) 


Connection Mode 


Connection- 
Oriented (C.O.) 


C.O. 


C.O. 


Connectionless 


Bit Rate 


Constant 


Variable 


Variable 


Variable 


ATM 

Adaption Layer 


AAL-1 


AAL-2 


AAL-3/4 

AAL-5 


AAL-3/4 





Table 2. 1 ATM B-ISDN Classes of Services 



6. ATM Connections 

Before information traverses an ATM network, a connection must be established. 
The connection setup prior to the sending and receiving of information makes ATM a 
connection oriented network. All information at the sending node will use the same "pipe" 
to reach the receiving node. After the receiving node retrieves all the information 
associated with the transmission, the connection is terminated. 

a. Virtual Channels 

The "pipe" or logical connection which the information traverses is the 
virtual channel. These channels are identified by the VCI in the header of each ATM cell. 
The VCI field has 16 bits. Theoretically, this allows up to 2 16 or 65,536 virtual channels in 
physical connections. Each channel can be assigned various speeds (kilobits per second to 
gigabits per second). 

b. Virtual Paths 

When virtual channels have the same origin and destination, they can be 
consolidated into virtual paths. These paths are defined by the VPI in the header of each 
ATM cell. The VPI field is 8 bits for UNIs and 12 bits for NNIs. The additional four bits 
replace the GFC bits which are not required for NNIs. Figure 2.7 depicts the relationship 
between VCIs and VPIs (de Prycker, M., 1993, p. 86). The bold lines between the ATM 
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nodes represents the physical connection and the non-bold lines depicts the logical 
connection (VCIs and VPIs) which are established and tomdown within the physical 
connections. 




Figure 2.7 ATM Network using Virtual Channels and Virtual Paths 



In Figure 2.7, a virtual path is established between subscriber A and 
subscriber C, transporting two individual connections, each with a separate VCI. Note 
that the VCI values used (3 and 4 in the example) are NOT translated in the nodes, which 
are only switching on the VPI field. In addition, a virtual path between A and B is 
semi-permanently established, using VCI values 1, 2, and 3. Another interesting point is 
that the link between A and node 1, uses 3 as the VCI value twice. This creates no 
problems, since the different VPI values allow the two endpoints (A and node 1) to 
discriminate between the two virtual connections, (de Prycker, M., 1993, p. 86) 
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c. 



ATM LAN EMULATION 



1. Overview 

When the 10 Mbps Ethernet LAN standard was finalized over 15 years ago, one 
would have never believed that 10 Mbps would not be capable of efficiently handling 
today's applications and a large workgroup of users. Though the 16 Mbps Token-Ring 
technology is faster than 10 Mbps Ethernet networks, the Token-Ring networks still is not 
capable of efficiently meeting today's, as well as future, application demands. Users are 
now competing more and more for computing resources and are bringing network (LANs) 
to a crawl. As a result, thousands of users have lost confidence with existing "customer 
premise" networks. Many have resulted to loading application software on their own 
computer to reduce the time required to bring up an application such as WordPerfect, 
Lotus 123, Excel, and Paradox. 

Because of the demand for more bandwidth to the desktop, and the development 
of multi-media applications, industry is developing new technology to satisfy user needs. 
Some technologies are based on traditional shared medium (FDDI, DQDB, Fast Ethernet), 
and others are based upon a switched point-to-point topology (Switched Ethernet, ATM) 
(Newman, P., 1993, p. 44). 

A shared medium design restricts the total capacity available to the LAN at the 
speed of the shared medium. This circumscription gets expensive at high speeds. Also, as 
more users are added to the shared medium, the capacity must be divided between the 
users. For example, if a 10 Mbps Ethernet LAN supported 25 users, and all 25 users 
accessed the network simultaneously, the average throughput per user would be 400 
kilobits per second (Kbps). ATM networks do not have this limitation; ATM can scale 
from small multiplexers to very large switches in both aggregate capacity and number of 
access ports. It can accommodate access ports from low speeds to very high speeds. 
ATM is also designed to handle multimedia traffic. Due to these capabilities, ATM is 
heavily considered as a technology that should support traditional LAN services. 
(Newman, P., 1993, p. 44) 
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To make ATM to the desktop more appealing to users, industry had to consider 
the installed base of existing LAN protocols and applications. The majority of installed 
protocol stacks rely on facilities provided by today's LANs. In order to use the current 
base of existing LAN applications, ATM must use a process known as LAN Emulation 
(LANE). In this process, ATM emulates services of existing LANs on an ATM network 
without the need of any change in the ATM terminal equipment's interface to the media 
access control (MAC) layer. (Kavak, N., 1995, p. 28) 

The LANE protocol emulates a LAN on top of an ATM network. The protocol 
defines the mechanisms to emulate either an IEEE 802.3 Ethernet or an 802.5 Token Ring 
LAN. Specifically, the LANE protocol defines a service interface for higher layer (that is, 
network layer) protocols, which is identical to that of the existing LANs, and the data sent 
across the ATM network are encapsulated in the appropriate LAN MAC packet format 
(Alles, A., 1995, p. 24). This does imply that any attempt is made to emulate actual MAC 
protocol of the specific LAN concerned (i.e., CSMA/CD for Ethernet or token passing for 
802.5). 

Figure 2.8 provides an illustration of the LANE protocol architecture (Alles, A., 
1994, p. 25). 




Figure 2.8 LANE Protocol Architecture 
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The current LANE protocol does not define a separate encapsulation for FDDI. 
FDDI packets must be mapped into either Ethernet or Token-Ring emulated LANs, using 
existing translational bridging techniques. Fast Ethernet (100Base-T) and 802.12 
(lOOVG-AnyLAN) can both be mapped unchanged into either the Ethernet or Token-Ring 
LANE formats and procedures, as appropriate, since they use the same packet formats. 
(Alles, A., 1995, p. 24) 

2. Connectionless Service Implementation 

ATM switches use connection oriented services to pass information. However, 
current LAN technologies use connectionless services as a method of communicating. To 
address this difference, ATM LANs use connectionless servers (CLSFs) to offer 
connectionless service at the MAC layer. 

In its simplest form, a CLSF is a packet switch attached to an ATM switch. All 
virtual channels carrying traffic that requires a connectionless switching service is directed 
by the ATM switch to the CLSF. The CLSF are connected together with virtual paths 
through the ATM switch to form a "virtual\overlay network." Figure 2.9 illustrate the 
implementation of connectionless data service. (Newman, P. "ATM Local Area 
Networks," 1994, p. 95) 
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Figure 2.9 B-ISDN Connectionless Data Service Implementation 



3. Emulated LAN Components 

The LANE protocol defines the operation of a single emulated system LAN 
(ELAN). Multiple ELANs may coexist simultaneously on a single ATM network since 
ATM connections do not collide. A single ELAN emulates either Ethernet or Token Ring, 
and consists of the following entities: (Alles, A., 1995, p. 26) 

♦ LAN Emulation Client (LEC): A LEC is the entity in an end system that 
performs data forwarding, address resolution, and other control functions for a 
single end-system within a single ELAN. A LEC also provides a standard LAN 
service interface to any higher layer entity that interfaces to the LEC. An ATM 
NIC or LAN switch interfacing to an ELAN supports a single LEC for each 
ELAN to which they are connected. An end-system that connects to multiple 
ELANs will have one LEC per ELAN. Each LEC is identified by a unique 
ATM address, and is associated with one or more MAC addresses reachable 
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through that ATM address. In the case of an ATM NIC, for instance, the LEC 
may be associated with only a single MAC address, while in the case of a LAN 
switch, the LEC would be associated with all the MAC addresses reachable 
through the ports of that LAN switch which are assigned to the particular 
ELAN. 

♦ LAN Emulation Server (LES): The LES implements the control function for a 
particular ELAN. There is only one logical LES per ELAN, and to belong to a 
particular ELAN means to have a control relationship with that ELAN'S 
particular LES. Each LES is identified by a unique ATM address. 

♦ Broadcast and Unknown Server (BUS): The BUS is a multicast server that is 
used to flood unknown destination address traffic, and forward multicast and 
broadcast traffic to clients within a particular ELAN. Each LEC is associated 
with only a single BUS per ELAN, but there may be multiple BUSs within a 
particular ELAN that communicate and coordinate in some vendor-specific 
manner. The BUS to which a LEC connects is associated with the broadcast 
MAC address. In the LES, this is associated with the broadcast MAC address 
("all ones"), and this mapping is normally configured into the LES. 

♦ LAN Emulation Configuration Server (LECS): The LECS is an entity that 
assigns individual LANE clients to particular ELANs by directing them to the 
LES that correspond to the ELAN. Locally, there is one LECS per 
administrative domain, and this serves all ELANs within that domain. 

Though the current LANE specification define two types of ELAN, (Ethernet and 
Token-Ring), the specification does not permit direct connectivity between an Ethernet 
ELAN and a Token-Ring ELAN. The two ELANs must interconnect through an ATM 
router which acts as a client on each ELAN (Alles, A., 1995, p.26). 

Another important note to mention is that the aforementioned server components 
can run on any device with ATM connectivity. However, for the purpose of reliability and 
performance, most vendors will more than likely implement the server components on 
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ATM switches or routers, rather than a workstation or host. An illustration of LANE 
protocol interfaces are provided in Figure 2. 10. 




Figure 2. 10 LANE Protocol Interfaces 

t . 



4. Traffic Management 

As with an ATM WAN, ATM LANs will more than likely have to provide two 
classes of traffic, guaranteed and best-effort. Guaranteed traffic is traffic (e.g., video, 
voice) for which a certain quality of service (QoS) (cell delay, cell delay variation, cell 
priority, cell loss, type of information that will be transmitted, speed) is provided by the 
network. The guarantee establishes a contract between the traffic source and the network 
(Newman, P., "Traffic Management for ATM Local Area Networks," 1994, p. 45). 
Before the contract is finalized, and a connection is set up between the origin and the 
intended destination, the network will query itself (traffic, available bandwidth) to 
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determine if it can offer the requested QoS. The network will also monitor the traffic to 
ensure that the transmission stays within the contracted parameters. 

The network ,or switching hardware, must ensure that QoS for guaranteed traffic 
is not adversely affected by best-effort traffic. This can be accomplish by creating two 
buffers in the switch hardware, one for guaranteed traffic and the other for best-effort 
traffic. The queue service algorithm always serves the guaranteed traffic in preference to 
the best-effort traffic. Figure 2.11 provides a general illustration of the two buffers 
(Newman, P., "Traffic Management for ATM Local Area Networks," 1994, p. 45). 
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Figure 2.11 Output Buffer with Two Classes of Traffic 



In an IEEE 802 LAN, the shared medium provides the shared bandwidth and the 
MAC protocol is the arbitration mechanism by which the bandwidth is shared between the 
contending users. In an ATM switch, each output port is a pool of bandwidth that need to 
be shared dynamically between all connections currently sending best-effort traffic across 
it. Some congestion control scheme must be implemented in an ATM LAN to support the 
statistical sharing of bandwidth between competing stations without prior bandwidth 
reservation. To date, three approaches are available for congestion control: 
over-provision in terms of bandwidth or buffers, loss mechanisms, and delay mechanisms. 
(Newman, P. "ATM Local Area Networks," 1994, p. 95) 
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Over-provision has its congestion limitations in both bandwidth and buffering. 
Bandwidth is fairly obvious: if bandwidth is overly allocated, then this reduces the 
capability of the ATM switch to provide services to an abundance of simultaneous users. 
Regarding buffering, if the delay through the buffer exceeds the retransmission time-out of 
the higher layer protocols, more retransmission traffic will be introduced to the network 
while the network is congested. 

Loss mechanisms discard cells during periods of congestion. However, this leads 
to a problem of creating more traffic or congestion on the network. Each discarded cell 
may belong to different packets. As a result, each packet must be retransmitted and 
bandwidth is wasted by the onward transmission of the remaining cells from corrupted 
packets. Various approaches have been explored to address this problem. One in 
particular is the use of cell loss priority. The ATM switch would discard low priority cells 
rather than high priority cells. This approach is very difficult to implement. Methods 
cannot be visualized as to how data traffic could be coded into two loss priorities at the 
MAC sublayer. 

Delay mechanisms use negative feedback from the point of congestion back 
towards the source to reduce the traffic entering the network. Forward explicit congestion 
notification (FECN) sends a congestion indication along the forward data path to the 
destination. The destination then takes some action to cause the source to reduce its 
transmission rate. Backward explicit congestion notification (BECN) sends the congestion 
indication directly back to the source along a return path. On receipt of this indication the 
source reduces its transmission rate directly. BECN can respond to congestion more 
rapidly than FECN but requires congestion notification cells to be inserted into the 
network. On the other hand, FECN can simply mark a bit in the cell header as it passes 
through the point of congestion. Other delay mechanisms have been proposed that use 
credit or backpressure on each virtual connection, on a link-by-link basis between switches 
and ultimately back to the source. This approach offers much tighter flow control, but is 
considerably more complex to implement. (Newman, P. "ATM Local Area Networks," 
1994, p. 96) 
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5. 



LANE and Virtual LANs 



Vendors use LANE to provide virtual LAN services on an ATM network. The 
virtual LANs are implemented on switched internets using a combination of LAN 
switching (bridging), ATM end systems (servers, using ATM NICs), and routers with 
ATM interfaces ("ATM routers"). These devices are all connected to an ELAN. The 
ELAN looks and functions like a typical LAN except for the bandwidth as far as either end 
systems attached to the LAN ports on the LAN switches, or the higher layer protocols 
operating within the ATM hosts or routers are concerned (Alles, A., 1995, p. 31). 

Implementing a virtual LAN using LANE has many advantages; one in particular is 
network management. Through network management, and the use of mechanisms such as 
the LECs, the network administrator can set up several ELANs across a single ATM 
backbone, and then assign LAN switch ports or ATM hosts to the different ELANs, 
independent of the physical location of the devices (Alles, A., 1995, p. 31). This process 
removes the physical location limitation of current LANs. As a result, the physical 
location of the devices no longer determines the LAN segment to which the devices can be 
connected. 

Virtual LANs also give the network administrator the ability to change or 
reconfigure virtual networks without changing the cabling plantas the organization work 
flows or processes change. This helps reduce the cost of moving or adding personnel. 

Though virtual LANs have great benefits, there is also a downside. Because 
LANE is a LAN bridging standard, ELANs are susceptible to broadcast storms. This 
tends to limit ELANs to small workgroup. As a result, large networks are likely to 
support a large number of virtual LANs (ELANs). 

An illustration of connectivity between ELANs are provided in the Figure 2. 12. 
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D. ATM STANDARDIZATION PROCESS 

Prior to October 1991, ATM or B-ISDN standards were established by standard 
making bodies such as the International Telecommunications Union (ITU) (formerly the 
International Telegraph and Telephone Consultative Committee (CCITT)), and the 
American National Standards Institute (ANSI). These organization primarily focused on 
future public B-ISDN networks and often took years to finalize standards. Manufacturers 
became concerned that high bandwidths requirements for end users (customer premises 
equipment (CPE) and private switching equipment) would become more prevalent than the 
need for high bandwidth for public networks and wanted to expedite the standards making 
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process. As a result, these manufacturers (CPE vendors, public equipment vendors), 
telecommunication operators, and users formed the ATM Forum which is the "premier" 
ATM standards body. 

The ATM Forum has more than 700 member companies, and it has five 
committees: the Technical Committee, three Marketing Committees for North America, 
Europe and Asia-Pacific, and an Enterprise Network Roundtable. 

The Technical Committee is a single worldwide committee and primarily focus on 
promoting a single set of specifications to ensure interoperability between all vendors as 
ATM products and services become available (http:/www.atmforum.com/atmforum/ 
atm_introduction.html, p.l). This committee has done work on User-Network Interface, 
Data Exchange Interface (defines how existing network equipment such as bridges, 
routers, and hubs can act as front-end processors to an ATM network), LAN Emulation, 
and Broadband Inter-Carrier Interface specifications. The Technical Committee is also 
working on key areas such as traffic management, signaling, physical interfaces, network 
management, service aspects and applications, and testing. Appendix A is a Technical 
Committee update which provides a status report of current work items as of December 
1995 (Hold, D. F., 1995, p. 11). 

The ATM Market Awareness and Education Committee (MA&E) functions as the 
public affairs agencies for the ATM Forum. Their primary focus is to provide marketing 
and educational services for the understanding and acceptance of ATM technology. 

The Enterprise Network Roundtable Committee consists of end-users. This 
committee interacts on a regular basis with (MA&E) to ensure that ATM technical 
specifications meet their needs. 
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E. ATM IMPLEMENTATION 

Because ATM is scaleable from a LAN environment to a WAN environment, it can 
be applied in a WAN, MAN, or LAN. The technology can also be used in all three 
environments simultaneously, thus creating a "pure" ATM network. The next three 
sub-subsections discuss ATM networks in WAN, MAN, and LAN environments. 

1. ATM WAN 

ATM over a WAN provide greater bandwidth over long hauls. It gives the user 
the capability to transmit data, voice, and video over one ubiquitous network, instead of 
having three separate networks for voice, data, and video. Figure 2.13 shows the use of 
ATM in a wide area. 
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2 . 



ATM MAN 



A MAN is a network capable of providing high speed (more than 1 Mbps) 
switched end-to-end connectivity across distances ranging from 5 to 50 km. This allows a 
MAN to span an entire university campus, an entire city, or an office park. Like an ATM 
WAN, an ATM MAN allows the simultaneous carrying of different types of traffic such as 
data, voice, and video. These characteristics make the MAN complementary to the 
definition ofB-ISDN. (dePrycker, M., 1993, p. 259). 

The Advanced Technology Demonstration Network (ATDnet), an ATM MAN, is 
currently operational in the Washington DC metropolitan area. ATDnet is a high 
performance networking testbed which is intended to represent a possible future MAN. It 
uses ATM and Synchronous Optical Network (SONET) technologies to connect six 
federal Agencies: the Advance Research Project Agency (ARP A), the Defense Information 
Systems Activity (DISA), the Defense Intelligence Agency (DIA), the National 
Aeronautics and Space Administration (NASA), the Naval research Laboratory (NRL), 
and the National Security Agency (NSA). 

The ATDnet concept is to interconnect these agencies with high speed fiber optic 
transmission media, and to overlay these media with SONET and ATM protocols. The 
initial deployment operated at OC-48 data rates (approximately 2.4 gigibits/second), but is 
designed to scale upwards to technology-limited data rates. Pair-wise and multiple party 
research initiatives and experiments are planned over the lifetime of the testbed. 
Experimental testing of the bitways and a diversity of service and applications experiments 
are intended to gain insight into the potential of this new performance level (Edicott, D., 
1994). 

Figure 2.14, on the next page, depicts the testing of the ATM MAN during 1995. 
Following the installation of the additional pair of fibers, each government site had 
four-fiber, OC-48 SONET service to the add/drop multiplexer (ADM), a Metropolitan 
Point of Presence (MPOP). Initially, each on-site MPOP had two OC-3 (155 MBits/sec) 
service connections to on-premise ATM switches. 
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ATDnet Final Configuration 

(June 95) 




Figure 2.14 June 1995 ATDnet Test Strategy 



Each participating agency in the ATDnet is responsible for on-premise routing, and 
local distribution of ATM and SONET traffic is the individual responsibility of each 
participating agency (Edicott, D., 1994). Typical configurations may include ATM service 
to scientific/engineering workstations, databases and file servers, high performance 
computers, and high resolution, and 3D display devices. Figure 2.15 provides a general 
idea of the ATM configuration for DISA. 
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Figure 2.15 DISA ATDnet Site Configuration 



3. ATM LAN 

Implementing ATM on a LAN will give the user tremendous bandwidth at the 
desktop. Instead of the bandwidth being shared between the users on the LAN, the vast 
bandwidth will be dedicated to the user during data transfer. This is accomplished by 
replacing the shared medium with a centralized switch. By having additional dedicated 
bandwidth to each workstation or personal computer, users are capable of accessing more 
powerful applications such as video teleconferencing to the desktop and shared 
multi-media applications. Figure 2.16 illustrates an ATM LAN. 
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Figure 2. 16 ATM LAN 



F. CHAPTER SUMMARY 

ATM has numerous advantageous over existing networking technologies (frame 
relay, ISDN, shared media). One in particular is ATM's ability to service different types of 
information (data, voice, and video). ATM is also scaleable in speed (Mbps to Gbps), and 
geography (local, metropolitan, and wide areas). Because ATM is scaleable in the local, 
metropolitan, and wide area, network management is simplified. The same set of tools can 
be used on the various sizes of the network. This reduces both training cost and time. 
Another key point in ATMs favor is its ability to dedicate bandwidth to each end-unit, 
instead of having to share bandwidth like Ethernet and Token-Ring technology. Finally, 
ATM can run on existing cabling plants (twisted pair, coax, and fiber). This allows 
end-users the usage of their current cabling plant instead of having to replace it. 
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III. ATM IMPLEMENTATION ISSUES 



A. INTRODUCTION 

1. Purpose of Chapter 

This chapter discusses implementation issues affecting the ATM technology as a 
whole. Many of the issues relate to ATM LANs and how they function. Some issues are 
only applicable to ATM backbones, MANs, and WANs. However, because of then- 
significance, and the possibility of connecting a redesigned Systems Management's 
laboratory LAN to the Naval Postgraduate School campus backbone, these issues are also 
discussed. 

Because ATM standards are evolving, many implementation issues discussed in 
this chapter may be resolved by the time this thesis is published. 

2. Standardization 

Given ATMs capabilities, it alone holds the promise of a single technology 
supporting high performance data, voice, and video services through the seamless 
integration of local and wide area networks, including those in the tactical theater of 
operations. 

As with any new technology, risk is a major factor, and this is particular true with 
ATM. Standards are still evolving, and many manufacturers have been reluctant to wait 
for concrete specifications. Due to this, many products have been marketed that only have 
the capability to operate with the manufacturer's, or very few vendors', equipment. Many 
of these "stove pipe" network products are headed for the orphanage once a real ATM 
specification set is agreed on, because they will face software incompatibility with many of 
the high-bandwidth applications that drive the demand for ATM. (Gallagher, S., 1995, p. 
40) 

Areas in which standards have not been established, or still evolving are LAN 
emulation, signaling, congestion and flow control, Internet Protocol (IP) over ATM, 



31 



firewalls, and AAL compatibility. The subsequent sections of this chapter discuss these 
issues. 



B. LAN EMULATION 

1. Problem 

As discussed in the previous chapter, the function of the LANE protocol is to 
emulate a LAN on top of an ATM network. The protocol makes the ATM network 
behave like an Ethernet or Token-Ring network, even though, the network is running at a 
much faster bit rate. 

The current LANE protocols (Phase 1) specify only the operation of the LAN 
Emulation User-to-Network Interface (LUNI) between a LEC and the network providing 
the LANE service. No specifications have been finalized for the functioning of the LAN 
Emulation Network-to-Network Interface (LNNI). The LNNI operates between the 
server components within a single ELAN system. The Phase 1 LANE protocols also do 
not allow for the standard support of multiple LESs or BUSs within an ELAN. As a 
result, these components are a single point of failure and a potential bottleneck. The 
interactions between each of the server components in the LANE Phase 1 protocol are 
currently left unspecified, and will be implemented in a proprietary manner by vendors. 
(Alles, A., 1995, p. 26) 

Figure 3.1 illustrates of the LUNI and LNNI interfaces. 
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Figure 3.1 LANE Protocol Interfaces 



2. Projected Release of LNNI Standard 

The ATM Forum is currently working on a Phase 2 LANE protocol. This 
protocol will specify LNNI protocols to allow for redundant LESs and replicated BUSs. 
The LNNI protocols will specify open interfaces between the various LANE server 
entities (LES/LES, LES/LECS, and BUS/BUS). The protocols will also allow for 
hierarchies of BUSs for greater scalability within ELANs. The projected completion data 
of the LNNI protocols is 1996. 



33 



c. 



NETWORK MANAGEMENT 



1. Overview 

Today's network management architectures and tools are not designed to handle 
the speed and complexity of ATM networks. These management solutions are developed 
to manage router or time division multiplexing (TDM) based networks, and cannot meet 
the critical requirements to control and operate an ATM network. 

ATM fundamentally changes the landscape of today's networks. The 
connection-oriented environment, varying classes of services, and higher volume of 
multiple traffic types differ significantly from yesterday's staticly configured, standalone 
networks. As a result, ATM networks require a new management model, one which takes 
these differences into account. (Alexander, P., 1995, p. 47) 

2. Problem 

With the virtual networking capabilities associated with ATM, the traditional 
physical and logical network management capabilities are greatly complicated by the 
addition of voice and video over the same network infrastructure. Thus, the entire 
network must be perceived as one entity, not as multiple networks. Network managers 
will no longer be able to troubleshoot their ATM-based network like they do today on 

shared media LANs by only attaching a protocol analyzer. Furthermore, with the 

currently envisioned corporate enterprise networks where the management domain spans 
from the desktop to the wide area, high volumes of network management and control data 
coupled with connection-oriented environment make the problems extremely more 
complex. More and more, users are discovering that managing the switched ATM 
environment with a single Unix-based simple network management protocol (SNMP) 
system is becoming impossible. In addition, SNMP itself raises issues of security, 
scalability, and efficiency. (Federline, G. E., 1995, p. 70) 

The new challenges ATM network management applications must address are 
multipoint connectivity, virtual connections, multiple classes of services, and high-speed 
cell network. If these areas are not addressed, the ATM network will run inefficiently and 
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ineffectively. Also, ATM's vast capabilities over current shared-medium networks will not 
be as great. A brief summary of the areas that should be addressed are provided in the 
following sub- sub sections ( Alexander, P., 1995, p. 48). 

a . Multipoint Connectivity 

ATM is a multipoint network architecture. Managing the network means 
managing multiple links from each switch, and multiple paths throughout the network. 
The task of managing multipoint connections in a WAN that uses an underlying TDM 
network has been largely performed be routers. This two-tiered management approach 
does not solve the problem of expensive, wasted bandwidth in the router portion of the 
network; it simply increases the complexity of the overall management task. 

b. Virtual Connections 

Each connection in a TDM network is a physical link carrying several 
channels defined through the process of time division multiplexing. ATM networks use 
virtual connections defined by virtual path and virtual channels identifiers carried in each 
cell. These virtual connections typically use several different physical links within the 
network, requiring much more sophisticated service provisioning than TDM and 
router-TDM networks. 

c. Multiple Classes of Service 

Each ATM class of service is defined be specified quality of services (QoS) 
parameters and guarantees. Every virtual connection has a specified guarantee of service, 
and each must be managed from end-to-end, based on the requisite QoS. At the same 
time, an individual connection's class of service must be managed in relation to other 
virtual connections in the network using different classes of service. Carriers and large 
enterprise network operators are no longer simply managing physical connections, but are 
now responsible for assuring the quality of many virtual connections. 
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d. High-Speed Cell Network 

As discussed in the previous chapter, ATM services use small, fixed-length 
cells running over a high-speed transmission infrastructure. This poses three challenges: 

♦ A problem in one part of the network can affect a large portion of the network 
or even the entire network before it can be reported to the central management 
station. In this situation, the network must be capable of addressing the 
problem before the information reaches the management station. 

♦ The network management system must be capable of handling a large number 
of fault messages stemming from a single fault. Broadcasting all fault 
messages to all management stations in the network can itself cause 
congestion. A different fault reporting procedure is required. 

♦ A large amount of data must be collected and reported to provide useful 
information about network trends and events for billing, analysis, and planning. 
SNMP is not capable of forwarding this data to central management for 
efficient storage and processing. 

3. Projected Resolution of ATM Network Management 

No date has been set as to when complete ATM standards and specifications for 
network management will be released. Also, network management, though it is important, 
is not a priority on the ATM Forum agenda. Because the ATM Forum has not shown a 
critical interest in network management, vendors are designing their own network 
management protocols to address the aforementioned potential network management 
problems, and to meet customers' needs. These actions will result in compatibility and 
interoperability problems as ATM WANs are connected. The WANs will consist of 
multi-vendor products, and if these products use various network management functions 
with non-standard protocols and interfaces, the users will not be able to effectively 
manage end-to-end connectivity across the network. Nor will the user be able to access 
the level of activity analysis necessary for effective network planning (Alexander, P., 1995, 
P 49). 
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D. SIGNALING 



1. Overview 

Before any information exchanges between end points, some type of signaling is 
performed to setup connectivity to establish virtual circuits. This signaling is initiated by 
the requesting user for negotiation with the network with respect to available resources 
(VCI/VPI, throughput, and QoS). The signaling is also performed over a separate 
signaling virtual channel. 

In order for the signaling to occur, the user and the network must understand the 
request and the response. To do this, standards are a must. A set of signaling standards 
have been established, and they are the foundation upon which switched ATM services 
will be built. 

While the initial standards have some limitations, and can only cope with relatively 
simple calls, they form a starting point from which manufacturers and operators can begin 
to offer switched services on their ATM networks. (Jeffrey, M., 1994, p. 1) 

2. Problem 

The ATM Forum published the first signaling standard, the User Network 
Interface (UNI) version 3.0. This standard included a basic signaling protocol for LAN 
environments with local ATM switches and terminals. The ITU's UNI protocol has been 
completed in ITU-T Recommendation Q.2391 (previously known as Q.93B), and is 
closely aligned with UNI v3, but is designed for communicating with public networks. 

UNI v3 and Q.2391 are similar in that they only support the "Release 1" service. 
This is limited to simple ATM calls with a single connection to a single party (Type 1 
connection). Also, the bandwidth for the call is specified by the caller and cannot be 
negotiated with the called party, nor can the bandwidth be changed during the life of the 
call. This basic service is sufficient for many purposes, including LAN interconnect and 
the transport of most POTS and ISDN services. However, the service is lacking when it 
comes to using the network for multimedia applications such as video-on-demand. 
(Jeffrey, M., 1994, p. 1) 
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3. Projected Release of Complete Signaling Standards 

Following the release of "Release 1," the ITU begin defining the requirements for 
the subsequent stages. For manageability reasons, the stages have been segregated into 
Capability Sets. The next stage is the design and formulation of protocols for Capability 
Set 2 (CS2). CS2 protocols will be capable of the following: 

♦ Negotiation and Modification - The calling party will be able to offer the called 
party a choice of bandwidth options rather than the "take it or leave it" 
provided by Release 1 . 

♦ Point-to-Multipoint (Type 2) Connections - The ATM Forum's UNI v3 
protocol supports limited point-to-multipoint connection. As a result, the 
ITU's will more than likely adopt this approach to be compatible. 

♦ Multi-Connection Calls - CS2 will include the support for many point-to-point 
connections in the same call. This will allow the transport of service 
components (within a multimedia call) over bearers with appropriate 
bandwidth and QoS. 

♦ Multiple Multipoint Connections - This signaling protocol will provide ATM 
switches the ability to support a mixture of point-to-point, and point-to- 
multipoint connections in the same call. Some of the connections will not 
originate from the same source as others. 

♦ Multipoint-to-Point Connections - This will allow "fan-in" connectivity. 

♦ All-points to All-points - to provide a "bus" like interface where all ATM cells 
are copied to all parties on the connection. 

The final stage on the signaling protocols is Capability Set 3 (CS3). These 
protocols will oriented toward new intelligence and services. Some of the services include 
the following: 

♦ Internetworking with the Intelligent Network - This will allow the 
implementation of Freephone and Selective Redirection for ATM terminals. 
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♦ Embedded Multimedia Functions. 

♦ True Broadcast Service - This feature allows the support of Cable-TV style 
broadcast services over ATM networks. 

♦ Evolution towards Telecommunications Information Network Architecture 
(TINA) - This protocol allows the construction of future network control 
architecture from distributed computing principles. 

The CS2 capabilities should be available in 1995. Studies have begun on the 
requirements for CS3. The signaling protocols should support CS3 functions in 1996 or 
1997. 



E. CONGESTION AND FLOW CONTROL 

I. Problem 

Congestion control techniques are of utmost importance in an ATM network. 
Without these techniques, user traffic on the network could exceed the capacity of the 
ATM switches. This traffic overload would cause the ATM switch memory buffers to 
overflow, resulting in cell loss. The cell loss may require the retransmission of thousands 
of cells. 

Congestion-induced cell loss is more difficult to prevent in an ATM network than 
in networks using "today's" technology (shared medium), such as an Ethernet network. An 
Ethernet network uses the MAC to help prevent loss because hosts sense the network 
before transmitting data to prevent or minimize collisions. In contrast, on an ATM 
network each host is connected to the switch using dedicated links. These links cannot 
sense if cross traffic will be encountered at intermediate switches. Since switch buffering 
is limited, and the transmission rate is fixed, buffer overflow can easily happen. 
(Brustoloni, Jose' Carlos, 1994, p. 324) 

The complexity of the cell loss problem is compounded by the limited number of 
overhead bits available to exert control over the flow of user cells. This area is currently 
the subject of intense research, and no consensus has emerged for a full-blown traffic and 
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congestion control strategy. Accordingly, ITU-T has defined a restricted initial set of 
traffic and congestion control capabilities aiming at simple mechanisms and realistic 
network efficiency; these are specified in 1.371. The ATM Forum has published a 
somewhat more advanced version of this set in the ATM UNI Specification 3.0. [Stalling, 
W., "ATM Congestion Control: A Practical Issue for Users and Providers," 1995, p. 34] 

2. Release of Congestion and Flow Control Standard 

The ATM Forum's congestion control standard was decided between two 
solutions, a credit-based scheme and a rate-based scheme. The credit-based solution 
requires window flow control on a per-link, per-VC (virtual connection) basis. Each link 
has a sender node and a receiver node that maintain a separate queue for each VC. The 
receiver determines the number of cells the sender can transmit by monitoring the queues 
on each VC, then issues a "credit" that determines how much data the sender can transmit. 

The rate-based scheme provided end-to-end control using single-bit feedback. The 
switch monitors the network by using the feedback bits. When congestion is detected, the 
switch adjusts the data rate until the heavy traffic goes away. 

The Forum selected the credit-based scheme because it allows zero cell loss, while 
the rate-based scheme requires that the switch be capable of sufficient buffering to prevent 
cell loss. (Chemicoff, David P., 1995, p. N3) 

F. IP OVER ATM 

1. Overview 

IP runs over various transmission media, including Ethernet, Token-Ring, Fiber 
Distributed Data Interface (FDDI), X.25, Frame Relay, Switched Multimegabit Data 
Service (SMDS), and many others. Now procedures must be formalized to run IP over 
ATM. 

IP is the "glue" which allows the variety of protocols to communicate across 
networks or the Internet. Each protocol can be viewed as running in its own subnet. The 
subnets are connected by routers to form the internet. As shown in Figure 3.2, the 

sending host computer formats (encapsulates) an IP packet to send to the receiving host. 
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This BP packet is encapsulated within the subnet protocol of subnet A and delivered to the 
router between subnets A and B. The router strips off subnet A's protocol information, 
and retrieves the IP packet. The packet is then encapsulated in subnet B's protocol. This 
process continues until the original IP packet reaches the receiving host. 




Figure 3.2 An Internet with Four Subnets 



2. Problem 

The primary problem or difference between IP and ATM is that IP is 
connectionless oriented and ATM is connection oriented. On an IP network, no 
connection is set up before any information is sent from the sending node to the receiving 
node. Also, the information or packets may traverse different paths before reaching the 
destination. At the destination, the packets are resequenced and reassembled to obtain 
the original message. 

On an ATM network, a connection or virtual path is established between the end 
points before the sending host transmit information down the path. The information or 
cells arrive at the destination in the same order that they were transmitted. Therefore, no 
resequencing is necessary. 
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Another difference between IP and ATM is the use of addresses. IP uses 
addresses as a means of sending packets to the appropriate destination. ATM does not 
use addresses. Instead, it uses virtual paths and virtual channels. 

3. Projected Release of IP over ATM Standard 

A number of protocols other then IP have already been standardized to operate 
over ATM (SMDS and frame relay). Technically, IP can run over one of these protocols 
over ATM. For example, if an organization already has frame relay routers in place using 
lease lines, the lease lines could be replaced by ATM service using ATM data service units 
(DSUs), which provide a router-compatible interface. (Witt, Michael, 1995, p. 54) 

Another alternative of running IP over ATM is to change or not use BP. This step 
would allow direct mapping between TCP and connection-oriented services. Though the 
method may have some advantages, it is a big step away from the TCP/IP architecture. 
As a result, this alternative will more than likely not be chosen. 

The Internet Engineering Task Force (IETF) BP over ATM working group is 
currently writing proposed standards for IP over ATM. The working group fielded two 
draff standards or request for comments (RFC) that address running BP over ATM. 

RFC 1483, "Multiprotocol Encapsulation over ATM Adaption Layer 5," discusses 
a number of different protocols that may be either routed or bridged over ATM networks. 
This draff covers protocol multiplexing and encapsulation issues. It defines two possible 
methods of multiplexing, and specifies the encapsulation format to be used with each 
method (Witt, Michael, 1995, p. 54). 

RFC 1577, "Classical IP and ARP over ATM," addresses IP over ATM 
specifically. It uses the term "classical model" to describe ATM integrated with BP as a 
standard subnet protocol. This protocol would match the BP addresses to their 
corresponding ATM addresses (Alles, A., 1995, p. 36). 

No projected date has been set as to when the BP over ATM standard will be 
completed. Because the IETF is independent of the ATM Forum and anyone can be a 
member of the ITEF, it may be sometime before the standard is released. 
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G. APPLICATION PROGRAMMING INTERFACE (API) 



1. Problem 

Vendors and users have two varying views of the use of ATM technology. The 
manufacturers feel that the technology should be used to increase bandwidth in corporate 
LANs and WANs, while users envision ATM being extended to the desktop. 

Though these views have "opposite" poles, both parties agree that in order to 
increase the demand of ATM to the desktop, a new class of applications must be 
developed to exploit the ATM technology. These new applications would use services 
provided by ATM networks, such as switched virtual circuits, specification of bandwidth, 
and QoS guarantees. These services are not available in today's Ethernet or Token-Ring 
environments. If new ATM applications are not developed, users will have little or no 
incentive to install ATM NICs in their desktops. Instead, they may upgrade their network 
to Switched Ethernet technology, connecting to ATM backbones to meet their bandwidth 
needs. (Harford, J., p. 19) 

Though there is a lack of API standards, many leading-edge ATM vendors are 
shipping or planning APIs that allow access to the ATM protocol stack. However, the 
APIs are all different. As a result, application writers must tailor an application to a 
specific ATM vendor's NIC. This may cause application writers to avoid ATM, thus 
relegating the technology to the backbone. Also, the use of vendor-specific APIs create 
interoperability problems, and forces the user to one vendor or a group of allianced 
vendors. 



2. Projected Release of API Standards 

Recognizing the need for an ATM API, the ATM Forum chartered a working 
group to address this challenge. The group is currently defining a semantic (not syntax) 
specification of such an API. The semantic specification will provide details of the 
interface between an application and the underlying ATM protocol stack, but will leave 
room for different syntaxes to account for the operating environment and language 
bindings. For example, an application written in C for a UNIX environment might require 
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porting to an object-oriented workplace OS, but the porting would be simplified because 
the underlying ATM protocol implements the same services in both environments. 
(Harford, J., p. 19) 

The specifications the API working group is developing will not only be designed 
for portability, but also for multivendor interoperability. 

It is projected that the ATM API specifications will be completed in late 1995. 
However, vendor implementation is not expected until spring or summer or 1996. 

H. FIREWALLS 

1. Overview 

An unresolved issue related to public ATM networks is the use of firewalls. A 
firewall is a combination of software and hardware used to keep unauthorized individuals 
from accessing a private LAN. (Buerger, D. J., p. 79) The firewalls normally run on a 
dedicated workstation external to the LAN, but inside the router link to the internet. As 
an illustration, a firewall may allow FTP access from a public network to a private 
network. This same firewall may prohibit Telnet access. 

Firewall components normally consist of one or more of the three techniques: 
packet filtering, application gateways, and circuit gateways. A brief description of each 
technique is provided below (Buerger, D. J., p. 79). 

♦ Packet filtering is usually performed by a router as data packets pass through 
the router's interfaces. The filter reads fields in Internet Protocol (IP) packets 
such as source and destination IP addresses and TCP/User Datagram Protocol 
source and destination ports. By checking these fields, the packet filter can 
allow passage of trusted packets, or disallow passage of packets from 
unauthorized sources. 

♦ Application gateways are proxy servers that funnel approved users to the 
appropriate application server. For example, inbound Internet users who want 
to use a corporate E-mail, FTP, or WWW server could access those services 
only after authentication by proxy servers located outside the corporate LAN. 
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♦ A circuit-level gateway relays TCP connections between specific sources and 
destinations. These gateways do no filtering; they simply pass bytes back and 
forth. An example is a Telnet gateway, which would service the Telnet session 
once the gateway permits its establishment. 

2. Problem 

Many networking experts are not sure whether firewalls can be used in an ATM 
environment. The main problem is that once an ATM connection is established, no 
intermediate devices generally interpret or process any of the information traversing the 
connection. Once a connection is established between two end nodes, any data could be 
sent down the connection without visibility to network administration. While firewalls, or 
other security devices, could be implemented in the end systems, it is not likely to be a 
practical solution for most end units. (Alles, A., 1995, p. 23) 

Many proposals have been written recommending that firewalls be used at 
connection set-up time instead of on the transmitted data. Special information elements 
would be defined within the signaling message to indicate the type of access (specific 
application, Telnet, FTP, etc.) is required. The intermediate switches would then filter the 
connection set-up based on the information element, source and destination addresses, etc. 

Another approach to tackling the firewall issue is the use of ATM address filtering. 
Address filtering could be used at private, public, and shared WAN network points to only 
allow connectivity between trusted addresses, and prevent general connections. 

3. Projected Resolution of Firewall Issues 

Though the two aforementioned recommendations may have some utility, they are 
limited by the fact that little prevents an end system from lying about the use to which a 
connection would be used, since ATM connections generally terminate at lower levels 
within end system protocol stacks, and not at the actual applications. As a result, once a 
connection is set up, a node could send packets of any protocol type down the connection, 
and have these demultiplexed at the destination to any supported application, regardless of 
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the identity of the application to which the connection was set up to. (Alles, A., 1995, p. 
23) 

Cryptographic based authentication mechanisms is a feasible solution to tackle this 
problem. These mechanisms can be added to the ATM signaling. 

The ATM Forum has begun preliminary work on using security mechanisms. 
However, it will be some time before complete specification are released. In the 
meantime, network administrators continue to use routers as security walls. Some routers 
are even used to connect two ATM switches to each other. Though this type of set up 
affects performance and service, many network administrators prefer this type of solution 
to not having any firewall protection. 

I. CHAPTER SUMMARY 

Though ATM has tremendous capabilities and bandwidth power, many 
implementation issues must be addressed, and standards must be released addressing these 
issues. This chapter discussed several of the implementation issues, such as LAN 
Emulation, network management, signaling, congestion and flow control, IP over ATM, 
APIs, and firewalls. Failure to address these issues leads to compatibility and 
interoperability problems. To circumvent these problems, one would have to buy 
proprietary products and lock himself or herself into one vendor. This would place the 
organization at a tremendous disadvantage should the vendor discontinue manufacturing 
ATM products. 

Another key point to remember is that if the future specifications addressing the 
implementation issues are not clear and precise, vendors will implement the specifications 
using various interpretations. This too could lead to interoperability problems. To avoid 
this problem, the specifications must be clear. 

Several issues were addressed in the previous sections. However, there are many 
more issues which the ITU, ATM Forum, and applicable standards making bodies must 
address. One in particular is the frame relay, and cell relay compatibility problem. 
Though the Frame Relay Forum and the ATM Forum agreed on how frame relay and 
ATM interoperates, the agreement is rudimentary and needs additional work. The 
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specification falls short of full interoperability because it does not address transfer between 
a generic ATM interface, and a generic frame relay interface. Without this kind of 
base-level interoperability, the device on the ATM network must know that it is 
communicating with a frame relay device, and it must treat that device differently than it 
would another ATM device. It must run frame relay software, which means running two 
protocol stacks at the upper layer. This makes administration difficult, and can be costly 
in terms of processing power and resources. (Taylor, S.,1993, p. 23) 

Another implementation issue is voice over ATM. Though ATM has been 
"preached" about its ability to send data, video, and voice, the ATM primary focus has 
been data and video. The ATM Forum recently started a new work effort to study how 
voice can be carried efficiently by ATM, and a new ATM adaption layer (voice AAL) is 
being discussed. (Harford, Jim, "ATM must Make Way for Voice," p. 33) 

The final implementation issue that will be mentioned is cell efficiency (control 
characters, and information characters). Approximately 10% (5 bytes) of the 53 bytes of 
an ATM cell are dedicated to the header of the cell, and the remaining 90% (48 bytes) 
carry information. When comparing this information to Ethernet packets, usage of the 
ATM cell format is very inefficient. An Ethernet packet size ranges from 26 bytes to 
1,526 bytes. There are 26 control bytes in an Ethernet packet. This equates to 
approximately 0.017% of the total 1,526 bytes in a full packet being used as control 
characters. 
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IV. ASSESSMENT OF SYSTEMS MANAGEMENT S LAB LAN 



A. INTRODUCTION 

1. Purpose of Chapter 

The purpose of this chapter is to provide a general overview of the SM 
Department computer lab LAN. This chapter is not intended to discuss the intricate 
details of the network topologies of the LAN and how the various topologies function. 
Instead, the chapter will provide a macro-picture of how the computer labs are physically 
and logically connected, the types of topologies used, and the hardware and software used 
on the network. 

The SM Department computer lab network has been in transition for the past year. 
While this thesis was being written, PC LAN was installed on the network. Since then, the 
computer lab network has been upgraded to Windows for Workgroup (WFW). This 
upgrade is not included in the baseline assessment. 

2. General Overview 

The SM Department of the Naval Postgraduate School has three microcomputer 
labs which are located in Ingersoll Hall, rooms IN- 15 8, IN-224, IN-250. The labs in 
IN-224 and IN-250 are used as instructional labs; IN-158 is used for research. Only Naval 
Postgraduate School students, faculty, and staff are authorized to use the labs. 

A Token-Ring network interconnect the three labs, providing connectivity to two 
instructor computers, 41 user computers, ten servers, and an assortment of ancillary 
components. 

In addition to the Token-Ring network, the SM Department also operates a 3Com 
10 Mbps Ethernet LAN, a 230.4 Kbps AppleTalk LAN, and a PCLAN. The following 
sections provide detail information on these various networks. 



49 



B. 



TOKEN-RING LAN 



The Token-Ring network conforms to the IEEE 802.5 standard and operates at 16 
Mbps. The network establishes a ring topology using multi-station access units (MAUs) 
and shielded -twisted pair cabling. A depiction of the ring is provided in Figure 4-1. To 
better manage to network, the network has been segmented into three sections (OTR, 
4TR, and 8TR). These alpha-numerical designations correspond to rooms IN-250, 
IN-224, and IN-158, respectively. 




1. Topology 

The Token-Ring network uses a logical ring topology. Tokens and messages pass, 
uni-directionally, from station to station, with each station acting as a repeater. This type 

of network uses a token-passing scheme for network access. In order for a node to 
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transmit data, it first must gain control of the token. The token is a specific bit sequence 
that circulate amongst the nodes. Once a node possesses the token, it can transmit a 
message that is in its output buffer. 

To allow messages to be routed to a particular node or a group of workstations, an 
Internet Protocol address is assigned to each station. Communication is established and 
maintained using PC LAN version 1.21 software. 

Though Token-Ring is based on a logical ring topology, the computers are 
actually connected to MAUs using a physical star topology. A MAU serves as a 
multi-port hub connecting up to eight computers. The MAU routes messages between the 
stations to maintain the logical ring, while providing individual physical connectivity to 
each station. 

MAUs also contain two ports to connect to other MAUs. These ports are 
designated as Ring In (RI) and Ring Out (RO). Figure 4.1 illustrates how OTR, 4TR, and 
8TR are interconnected using the RI and RO ports of the eight MAUs which makeup the 
SM Lab Token-Ring LAN. 

To reduce crosstalk and noise, shielded twisted pair (STP) cabling is used to 
connect the MAUs and the computers. Network Interface Cards (NICs) or network 
adapters are installed in each computer to allow connectivity to the computers. 

2. Configuration 

a. Instructor and User Computers 

The instructor and user computers are 486/33 DX computers. Each 
machine is equipped with a regular suite of input/output devices such as keyboard, 
monitor, mouse, and dual floppy drives (3.5 and 5.25 inch). Several computers are 
equipped with additional peripherals such as modems, CD-ROMs, projectors, and 
scanners. Some computers also have 3270 emulation capability. 

Each computer has a CONFIG.SYS and an AUTOEXEC.BAT file in its 
root directory. The CONFIG.SYS file customizes DOS while it is being loaded into 
memory during the boot process and loads the various device drivers to establish a logical 
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between the device and the entire system. After DOS has been loaded into memory, the 
AUTOEXEC.BAT file is run. This file sets paths to the logical or physical disk drives and 
directories, loads specific operating files (when needed), and establishes environmental 
variables, as required. The AUTOEXEC.BAT file also sets parameters to display the 
current directory at the DOS prompt, and displays a standard screen. The screen display 
could either be a DOS prompt to load Windows or instructions to log into the network. 

The CONFIG.SYS and AUTOEXEC.BAT files are executed each time the 
computer is "booted." Their executions are automatic and transparent to the user. 

Besides the CONFIG.SYS and AUTOEXEC.BAT files, other batch files 
are used to allow the user quick and easy access to various applications on the network. 
These applications may be located on different servers. When the user exits the 
application, the batch file executes additional DOS commands to return the computer to 
the standard network configuration. 

b. Servers 

The Token-Ring network currently operates ten servers: eight 486 DX 33 
MHz computers and two pentium computers. The location of the servers is shown in 
Figure 4.1, page 51. 

IN-224 contains four of the servers. Two servers function as files servers, 
one doubling as a print server. The other two servers provide gateway access to the 
mainframe computer in the Church Computer Center (Ingersoll Hall). Nine of the user 
computers in IN-224 are configured with 3270 emulation software to access the 
mainframe computer via the Gateway servers. As a last note, all of the user computers in 
IN-224 operate as DOS-based machines and runs only DOS applications. 

The user computers in IN-250, the OTR segment of the Token-Ring 
network, can run either DOS- or Windows-based applications. These computers access 
the Pentium servers in IN- 158 to run applications. One of the three 486 DX 33 MHz 
servers provide print services to the users in IN-250. The remaining two servers provide 
no services. 
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Finally, the 486 server in IN- 158, the 8TR segment of the Token-Ring 
network, provides file and print services to five user computers. Like the user computers 
in IN-250, these computer run DOS- and Windows-based applications. 

c. Protocols 

The Token-Ring network not only uses the IEEE 802.5 protocol. It also 
uses Transmission Control Protocol/Intemet Protocol (TCP/IP), Terminal Emulation 
(Telnet) protocol, File Transport Protocol (FTP), and SIMPC. These protocols provides 
the following functions. 

♦ TCP/IP is a set of communications protocols that encompasses media access, 
packet transport, session communications, file transfer, electronic mail, and 
terminal emulation. All network traffic use these protocols while traversing the 
network. Also, this protocol is used to communicate with the mainframe 
computer in the Church Computer Center. 

♦ TELNET is a terminal emulation protocol that provides remote 
terminal-connection services. This protocol can be used to connect to either 
the computer center's mainframe or a workstation. 

♦ FTP is used in conjunction with TCP/EP to log in to a network or host, list 
files and directories, and transfer files. This can either be done between PCs, 
or a PC and a mainframe. 

♦ SIMPC is a terminal emulation program used in conjunction with a modem. 
This software allows a PC to connect to a mainframe or a workstation and 
transfer files between a PC and a mainframe. 

3. Token-Ring Segment 4TR (IN-224) 

This segment interconnects four servers (two gateway servers, and two file 
servers), an instructional computer, and 15 user computers. Three IBM 8228 MAUs 
provide the interconnectivity. STP cabling is used to connect the servers and computers 
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to the MAUs. A STP cable nan functions as a link to the campus backbone. Figure 4.2, 
on the next page, depicts the connectivity. 

Peripheral equipment such as a graphics scanner, an external CD-ROM reader, a 
Hewlett-Packard DeskJet 500 printer, and a video projection system are also located in 
IN-224. The scanner and CD-ROM reader are attached to user computers, and the 
projector is connected to the instructor computer. The printer is connected to the server 
designated as TN6M. 

The 2400 baud internal modems are installed in the instructor computer (TNI 8) 
and five user computers (TN20, TN21, TN22, TN24, and TN25). These modem are used 
to access the Computer Center's mainframe and Sun Workstations, or remote access to 
other networks. 

Nine computers (the instructor computer and eight user computers) have 3270 
emulation capability. These computers use the IBM 3270 User-version Emulation 
Software to connect to the Computer Center mainframe via the two 3270 Gateway 
Servers (TN0 and TNI). These servers access the mainframe through an IBM 3174-1L 
Controller. Coaxial cable is used. 

4. Token-Ring Segment 0TR (IN-250) 

This segment interconnects three 486 servers, an instructor computer, and 21 user 
computers. This segments comprises four MAUs which functions as the central hubs for 
up to eight computers. The MAUs are connected using the RI and RO ports. Figure 4.3, 
on page 58, provides a diagram of how the computers are connected to 0TR. 

Server N3 functions as a dedicated Systems Architect (a software design tool) 
server. No other services reside on this server. Server N6 provides no services, and 
Server N1 7 provides print services. 

The computers on this segment use WFW, and access DOS- and Windows-based 
applications from the Pentium servers in IN- 158. 

The instructor computer (N9) and six user computers (N10 through N15) are 
configured with 9600 baud internal modems. These modems allow access to the 
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Computer Center mainframe and the Sun Workstations. The modems also permit access 
to the Token-Ring network from remote locations. 




Figure 4.2 Token-Ring Segment 4TR (IN-224) 
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Figure 4.3 Token-Ring Segment OTR (IN-250) 



5. Token-Ring Segment 8TR (IN-158) 

IN-158 is the Software Metrics Lab. The segment in this lab comprises two 
Pentium servers, one 486 DX 33 MHz server, and five user computers. One MAU is 
currently used in this segment for interconnectivity. A third Pentium server will be 
connected to this segment in the near future. Figure 4.4, below, shows the current 
segment configuration. 

The Pentium servers (PN3 and PN6) provide DOS- and Windows-based 
application services to users in IN-250. These servers also run WFW. The 486 server 
(TN4) provides DOS- and Windows-based application services and print services to user 
computers in IN- 158. The third Pentium server will be configured as a Windows NT 
server when it is added to 8TR. 
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3270 emulation cards are installed in each user computer for coaxial connectivity 
to the mainframe via an IBM controller. 



Token-Ring Segment 8TR (IN-158) 




m 






Modem installed (2400 bp*) 

3270 Emulation (Direct Connection) 



Note: Thi# drawing show* the wiring *cheme of die 4TR Network; the diagram is not to scale. 

The Pentium system* run Windows for Work Group for users m IN250. 

* All computer are 286 systems except PN3 and PN6 which are Pentium*. 



Figure 4.4 Token-Ring Segment 8TR (IN- 158) 



C. ETHERNET LAN 

The Ethernet LAN runs at 10 Mbps and consists of a 3Com Server and four 486 
DX 33 MHz user computers. The server provides file and print services. A Hewlett 
Packard DeskJet 500 is attached to the 3Com Server. The server and user computers are 
individually connected in a star arrangement, using Thinnet coaxial cable, to an eight-port 
Ethernet Repeater. A separate port, the Attachment Unit Interface (AUI) Port, is used for 
connectivity to the Campus Backbone. The repeater is a centralize connection provides 
reliability and ease of connection and disconnection. 

Each user computer runs TCP/IP software. Although ENET4 is physically 
connected to the Ethernet Repeater, it is not part of the network. It does not run the 
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3Com software. It is configured for access only to the campus backbone using the 
TCP/IP software. 

Figure 4.5, on the following page, depicts the Ethernet LAN. 

D. APPLETALK LAN 

The AppleTalk network consists of six Macintosh Plus computers. One Macintosh 
Plus functions as the server. A Laser Writer is also connected to the AppleTalk network 
to provide printing capabilities. The Apple network uses its own Apple protocol. Another 
unique feature of this network is the use of proprietary AppleTalk cables and connectors. 
The network runs AppleShare software for file sharing and communications between the 
users. AppleTalk is used for print services. The AppleTalk LAN is dedicated to research, 
and will possibly be upgraded to Ethernet Standards. Figure 4.6, on the next page, 
provides a layout of the network. 

AppleTalk is a proprietary network standard and does not conform to IEEE 
standards. The network is baseband and functions in a bus topology. AppleTalk can 
function over STP, UTP, and fiber optic cable. It runs at a speed of 230.4 kilobits per 
second, and uses an access scheme similar to the Ethernet Carrier Sense Multiple 
Access/Collision Detection, or Carrier Sense Multiple Access/Collision Avoidance. 
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Figure 4.6 AppleTalk LAN 
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E. PCLAN NETWORK 

The PCLAN network comprises a server and two user computers. These 
components are connected through a translator (hardware). This network is a standalone 
network and functions as a test bed for implementing new network hardware and 
software. The server runs many DOS-based applications. 

F. CHAPTER SUMMARY 

This chapter provided an overview of the SM Department computer lab network. 
The labs use various network protocols to support the facets of LANs that to provide file 
and print services to NPS faculty, staff, and students. The servers provide either DOS- or 
Windows-based applications services, or both. The Token-Ring LAN has two Gateway 
Servers for access to the mainframe computer, and a dedicated run to the campus 
backbone. The Ethernet network also has a dedicated run for access to the campus 
backbone. Two LANs (AppleTalk and PCLAN) functions as stand alone LANs. 
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V. APPLICATION OF ATM TECHNOLOGY TO LANS 



A. PURPOSE OF CHAPTER 

The purpose of this chapter is to provide an illustration of an implemented ATM 
network and to design an ATM network that could replace the current lab network in the 
SM Department. I will discuss the Super computing 1995 Conference ATM network that 
was installed in the San Diego Convention Center. I assisted the coordinators of this 
ATM network while on thesis travel. 

Though Supercomputing 1995 ATM network supported powerful workstations 
and mainframe computers on site and across the United States, the first-hand knowledge 
and actual configuration of ATM switches is applicable to the design of an ATM network 
for the SM computer labs. 

B. SUPERCOMPUTING 1995 NETWORK 

1. Overview of the Supercomputing Conferences 

Supercomputing conferences provides computational scientists and engineers a 
worldwide forum to showcase their research. The scientists and engineers transport 
portions of their labs to the conference site, or connect their labs over high-speed 
networks to communicate, educate, and learn from one another. Presentations at 
Supercomputing promote the development of teams of computational scientists and 
computer scientists for large-scale problem solving. The presentations also foster 
technology transfer between scientists, industry, and future researchers. A third advantage 
of the conferences is the encouragement of collaboration among academia, government 
research labs, and industry. 

Two key demonstrations of existing technology and future technology shown at 
Supercomputing 1995 was the GII Testbed, and the High Performance Computing (HPC) 
Challenge. A summary of these demonstrations are provided below. (Korab, H. and 
Brown, M. D., 1995, p. 2) 
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a. GII Testbed 

The GII Testbed was an interactive 2D and 3D scientific visualization, and 
virtual reality demonstrations of research projects that used high-performance computing 
and communications to attack large scale problems. The applications were computed in 
the scientists' numerical labs, and then transmitted over the I-WAY (Information Wide 
Area Year, national scale, applications-focused, community-based ATM network) to the 
Supercomputing 1995 convention floor. The applications emphasized distributed, 
real-time heterogeneous computing, large data sets, remote instrumentation, collaboration, 
and advanced display devices. 

b. HPC Challenge 

The HPC Challenge was a forum for scientists who are on the leading edge 
to challenge the computational limit of heterogeneous computing in the race to the 
teraflop. The goal of the HPC Challenge was to assemble the greatest amount of 
computing power and speed to run a single scientific application on-site and over the 
I-WAY. 

Most of the GII Testbed and the HPC Challenge applications were highly 
graphical. These applications were displayed in the following advanced virtual reality 
environments. 

♦ Cave Automatic Virtual Environment (CAVE) - alOxlOx 9-foot 
room-sized, multi-person, high resolution 3D video and audio environment. 

♦ ImmersaDesk - a scaled-down version of the CAVE, about the size of a 
drafting table, that brings 3D virtual environment technology into the office. 
The ImmersaDesk is portable yet large enough to fill a persons field of view 
when he or she is seated in front of it. 

♦ NH/Wall - is a large projection display created from four 1280 x 1024 screens. 
Like the ImmersaDesk, images appear on one plane and can be in stereo. 
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2. Implementation of the Conference Network 

The network implementors and administrators used a variety of networking 
technology to provide connectivity to the participants, both on site and off site, of the 
Supercomputing conference. The technology ranged from ATM to FDDI, Ethernet, and 
Switched Ethernet. 

The participants had access to their research data via the I-WAY and the internet. 
The I-WAY, an ATM testbed, was an experimental, high-performance and high-speed 
network which linked dozens of the United States' fastest computer and advanced 
visualization machines. The I-WAY also provided the backbone for all the high-end 
networking activities during the conference. 

In order for the I-WAY to be accessible in major conference rooms, selected 
research and exhibit booths, video display kiosk, and other areas of the convention, the 
I-WAY was connected to the WAVE, the Wide Area Visualization Experimental. The 
WAVE LAN also supported visualization and virtual reality applications and video server 
technology within the convention center. Each application in the GII Testbed and the 
HPC Challenge accessed the WAVE through both ATM and Ethernet connectivity. 

A second network which functioned on-site was the SCInet. This network was the 
production network which provided a seamless infrastructure throughout the convention 
center. The SCInet also provided external connectivity to the I-WAY and the internet, as 
well as internal connectivity among the booths, meeting rooms, electronic mail-equipped 
rooms and kiosks. 

An illustration of the of the SCInet/I-WAY architecture overview is provided in 
Figure 5.1 on the following page. This figure provides a general idea of how the SCInet 
ATM cloud (network) accessed rooms and booths on-site, the I-WAY, the internet, and 
other sights. Figure 5. 1 also includes the WAVE ATM cloud which provided connectivity 
to Kiosks, SP2, and the GII Room. 
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The SCInet and the WAVE ATM fabric obtained access to the I-WAY and the 
internet through the San Diego Convention Center (SDCC) and the San Diego State 
Supercomputing (SDSC) points of presence (POPs). 

a. Hardware Configuration 

As mentioned, ATM, FDDI, Ethernet, and Switched Ethernet technologies 
were used to provide network connectivity throughout the convention center. Many 
network administrators used wireless network connectivity to maintain the network. 
Because this thesis focuses of ATM technology, I have omitted detail discussions of how 
users and network administrators used FDDI, Ethernet, Switched Ethernet, and Wireless 
network technologies. 
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Figure 5.2 depicts the ATM switch fabric and physical connectivity of the 
switches. Four Fore BX and four Fore BXE200 ATM switches implemented the ATM 
fabric. The BXs supported one 16-port card. The BXE200s contained four slots of 
which each slot could have functioned as a single 16-port switch. As a result, each 
BXE200 was capable of functioning as four separate switches. However, only two of the 
BXE200s utilized four 16-port cards. • 



ATM Switch Fabric 



WAVE4 WAVE3 WAVE2 




OC3sSM 

002 



Figure 5.2 ATM Switch Fabric 



The switches were connected using either single mode (SM) or multi-mode 
(MM) fiber. The speed of each fiber run ranged from 155 Mbps (0C3c) to 622 Mbps 
(0C12). As shown in the above figure, the fiber run between TCG and SDSC was 
capable of supporting throughput of up to 2.4 Gbps (OC48). 
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The SODA-CC BXE functioned as the central switch for connectivity to 
other switches, routers, and users. The users obtained I-WAY and internet access through 
the SODA-CC BXE. The routers provided connectivity to FDDI, Switched Ethernet, and 
Ethernet networks within the convention center. The remaining BXEs (WAVE1, 
SCINET2, and SCINET3) and the BXs (WAVE2, WAVE3, WAVE4, SCINET4) 
provided connectivity to the convention floor (booths, exhibits, conference rooms, 
meeting rooms, classrooms, etc.). 

b. Software Configuration 

The Fore BXE and BX switches were configured using software written 
specifically for them. One cannot guarantee that the software could run on a Cisco, 
Newbridge, or any other manufactured ATM switch. However, the software complied 
with ATM standards (UNI v3.0, etc.). By complying with the standards, the Fore 
switches were able to communicate with other brand name switches which also followed 
ATM standards. 

The Fore switches were setup individually to ensure that they could 
function in a stand-alone mode prior to connecting them to form the ATM network. As 
the switches were connected physically, logical connections were formed to pass 
information. These logical links were created using virtual circuits (PVCs or SVCs). UNI 
v3.0 or Fores proprietary software (SPANS) was used to establish the virtual circuits. 
The network administrators used UNI v3.0 for any connection connecting a Fore and a 
non-Fore switch or device to ensure interoperability. SPANS was used when Fore 
switches or devices were connected. 

3. Maintenance 

SNMP (Simple Network Management Protocol) functioned as the network 
management application. This protocol ran under the Fores proprietary network 
management graphics user interface (GUI) tool, Foreview. Foreview, specifically 
designed for the Fore switches, allowed the network administrators to view each switch, 
down to the port level. Instead of having to physically stand in front of the switch to 
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determine the status of each port, the network administrator could determine the status of 
the port be clicking on a graphical representation of the port displayed on his workstation. 

Foreview was also used to create, modify, or delete virtual paths and virtual 
channels. These paths, and channels were defined as either permanent (PVCs) or 
temporary (SVCs). When the PVCs were created, the port at the origin, destination, and 
intermediate ports, had to be identified. However, only the IP address of the origin and 
destination had to be identified when establishing a SVC. 

C. SYSTEMS MANAGEMENT'S COMPUTER LAB LAN 

1. Overview 

Chapter IV provided a general overview of the Systems Management's three 
microcomputer labs which are located in Ingersoll Hall, rooms IN- 15 8, IN-224, and 
IN-250. The lab in IN-158 is used for research; whereas, IN-224 and IN-250 are used for 
instructional purpose. 

A Token-Ring network interconnects the three labs providing connectivity to two 
instructor computers, 40 user computers, ten servers, and an assortment of ancillary 
components. In addition to the Token-Ring network, the SM Department operates a 
3Com 10 Mbps Ethernet LAN, a 230.4 Kbps AppleTalk LAN, and a PCLAN. The 3Com 
LAN is located in IN-224, and the AppleTalk LAN and PCLAN functions in IN- 15 8. 

ATM technology will now be used to redesign the Token-Ring and Ethernet LANs 
into one integrated LAN. The redesign is based on the PC LAN which was installed when 
this thesis was written. However, the redesign can easily adopt the upgraded PC LAN, a 
WFW configured network. 

To redesign the LANs, physical and logical topologies, as well as the hardware 
and software configurations must be addressed. For simplicity, the hardware configuration 
will include the physical topology, and the software configuration will include the logical 
topology. 
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2 . 



Hardware Configuration 



a. ATM LAN 

The ATM network, being designed, will conform to the ATM25 and 
ATM 155 standards. The ATM Forum's Physical Layer Working Group voted to adopt 
25.6 Mbps specification (the ATM25 standard) as the baseline for a medium-speed ATM 
physical connection specification (Duffy, C. A., 1995, p. 1). The new specification will 
allow the use of Category 3 UTP cable, and full-duplex 25.6 Mbps connectivity. This type 
of connectivity equates to approximately 50 Mbps throughput capability. 

Not only can ATM25 standard function over UTP, it can also run over 
STP, coax, and fiber. However, most vendors are manufacturing ATM25 switches which 
connect PCs using UTP. STP, coax, or fiber is used to connect switches over long 
distances, or distances that exceed UTP limitations, and to obtain higher throughput. 

The ATM 155 Mbps standard has been in existence for some time. 
Typically, fiber has been used to support this throughput rate. However, STP and 
Category 5 UTP are considered as viable and cheaper alternatives to fiber. Vendors are 
now producing ATM155 NICs which support STP and Category 5 UTP. 

Figure 5.3, on the following page, depicts the redesigned network. The 
network has six segments (OATM, 4ATM, 8ATM, 4EN, 4TR, and 8TR). The first 
number of each alpha-numerical designation, 0, 4, and 8, correspond to rooms IN-250, 
IN-224, and IN- 158, respectively. 
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SM Department ATM LAN 



25.6 Mbps ATM Switches (Stacked) 
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Campus Backbone 
Connection 
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Campus Backbone CompUtCTS Upgradedto ATM 
Connection Disabled 



Figure 5.3 Systems Management Lab ATM LAN 



Segments 4TR and 8TR (48TR) are interconnected to form a small 
Token-Ring that consist of nine computers. Three of the computers are located in 
IN-224; five computers are in IN- 158. All of these clients will have access to the 
Pentiums servers in IN- 158. 

The proposed network consists of five ATM switches and an ATM LAN 
Bridge. Of the five switches, four are ATM25 switches (stacked in groups of two) and 
one is an ATM155 switch. The ATM LAN Bridge functions as a bridge to allow ATM, 
Token-Ring, and Ethernet technologies to operate in one integrated network. 

Each ATM25 switch is capable of supporting up to 12 computers. Most 
vendors are designing ATM25 switches with 12 desktop ports. However, these switches 
are stackable using a Stacking Bus. 
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Because of the number of computers (user computers and servers) that will 
be upgraded to ATM, two or more stacked switches are necessary for IN-224 and 
IN-250. Figure 5.3 depicts only two stacked switches for IN-224 and IN-250. However, 
the number of stacked switches can be increased easily. 

Only one switch, an ATM155 switch, is necessary in IN-158. This switch 
will provide connectivity to the servers, the ATM25 switches in IN-224 and IN-250, and 
the ATM LAN Bridge. 

The 155 Mbps ATM switch in IN- 158 will provide high speed access to 
the servers and the switches in IN-224 and IN-250. This configuration will greatly 
enhance the throughput capability of the integrated network, particularly under the new 
WFW network configuration. In the WFW network configuration, the applications (DOS- 
and Windows-based) will reside on the Pentium servers (PN3 and PN6) in IN- 158. The 
155 Mbps connections to these servers will provide the users faster response time. 

Currently, Type 1 STP cable is in place to connect computers to the 
Token-Ring network. ATM25 is compatible with Type 1 STP cable, but most vendors 
are designing their switches to support UTP or Ethernet lOBaseT cable. IBM may be 
designing switches which are compatible with Type 1 STP cable. Should switches which 
are compatible with Type 1 cable be used, additional Type 1 cable may be required. In the 
current Token-Ring LAN, the Type 1 cable connects the computers to the appropriate 
MAU, and the MAUs are connected via Type 1 cable. In the case of ATM, each Type 1 
cable link must run directly to a port in the switch. The switches in IN-224 and IN-250 
will be stacked, and in a one location. 

Another area that requires addressing should Type 1 cable be used is the 
connectors. Very few, if any, switches have ports compatible with IBM Token-Ring 
Adapters. Instead, the switches are compatible with RJ-45, coax, or fiber connectors. In 
order to marry the Type 1 cable (DB-9 connectors) to the switch port, an intermediate or 
connector conversion must occur. 

Figure 5.3 also shows the fiber connectivity between IN-158, IN-224, and 
IN-250. Multi-mode fiber is the recommended medium because of the distance between 
the rooms, possibility of noise, and the 155 Mbps throughput. Many ATM25 switches 
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are capable of interconnectivity throughput of up to 155 Mbps. This throughput rate may 
exceed the Systems Management's requirement and the capability of the servers and PCs. 
However, the multi-mode fiber supports this throughput, and allows room for bandwidth 
growth. As faster servers and PCs are purchased, the throughput capability will be 
available to accommodate the increased demand for more bandwidth. 

Multi-mode fiber, STP, or Category 5 UTP can be used to connect the 
servers and the ATM LAN Bridge in IN-158 to the ATM155 Switch in IN-158. 

b. A TM Segment 4 A TM (IN-224) 

The redesigned network in IN-224 uses ATM, Token-Ring, and Ethernet 
technologies. Because IN-224 functions as the networks lab, the interconnectivity of the 
three network technologies provides students and staff hands-on experience in an 
integrated environment. 

In this environment, the Ethernet network (4EN) will remain intact. The 
only addition would entail linking the repeater to the ATM LAN Bridge. This attachment 
may require the use of one of the repeater ports. The ATM LAN Bridge must be capable 
of supporting a coaxial or RJ-45 connection. However, a coaxial cable is recommended 
because of the distance between the Repeater and the ATM LAN Bridge. The bridge will 
be located in IN- 15 8. 

The Ethernet campus backbone connection can be disabled or remain 
enabled to function as a backup to the Token-Ring campus backbone connection through 
the Cisco router. However, only one backbone connection is needed on the integrated 
network. 

The Token-Ring Segment 4TR is a much smaller version of the existing 
4TR segment. This redesigned segment is comprised of one MAU and three computers. 
However, 4TR is expandable up to six computers. One port is required for backbone 
connectivity. A second port is necessary to link the MAU to the ATM LAN Bridge. The 
RI and RO ports are used for connectivity to the MAU in IN- 158. 

Figure 5.4, next page, depicts the 4 ATM Segment. This segment consists 
of two ATM25 Switches for connectivity to a maximum of 24 computers. However, 17 
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of the 20 computers are designated to be upgraded to ATM. This leaves seven ports that 
are available for growth. 

Figure 5.4 also shows two new servers (Novell Server PN1 and Print 
Server) that will be upgraded to ATM. These servers replaced TN6M and TN3 during the 
WFW upgrade. 



IN-224 ATM LAN (4ATM) 




To IN-158 

(155 Mbps ATM Switch) 




X2278 x2284 x2285 



x2268 X2297 




Multi-mode Fiber 




25.6 Mbps ATM Switches (Stacked) 



gg - Modem installed (2400 bps) 



* 



3270 Emulation 



Figure 5.4 IN-224 ATM LAN (4 ATM) 



The two ATM25 switches that will service the 17 computers will be 
stacked on top of each other using the Stacking Bus Option. The Stacking Bus Option 
allows a group of ATM switches to be stacked on top of one another and function as one 
"combined" switch. 

Existing peripheral equipment (printers, a graphics scanner, an external 

CD-ROM reader, a video projection system, and internal modems) is included in the 
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proposed designed. These peripherals are connected to the same server or user computer 
that they are currently connected too in the existing Token-Ring and Ethernet LANs. 

Computers that currently have 3270 emulation capability will not loose this 
capability in the ATM LAN. These computers will continue to have the ability to connect 
to the Computer Center mainframe via the two 3270 Gateway Servers (TNO and TNI). 
These servers will continue accessing the mainframe through an IBM 3 174-1 L Controller. 

c. A TM Segment 0A TM (IN-250) 

ATM Segment OATM interconnects one 486 server, an instructor 
computer, and 22 user computers. Two switches are stacked using the Stacking Bus 
option. As with the 4ATM segment, each computer requires a dedicated STP or UTP 
cable run. Figure 5.5, below, provides a diagram of how the computers would be 
physically connected in the OATM segment. 

Unlike the original Token-Ring Segment OTR (IN-250), Servers N3, N6, 
and N17 are not used in Segment OATM. These servers were not included in the WFW 
upgrade. However, Print Server WFWPRT#1 was apart of the WFW upgrade. This 
server will provide print services. 

Each computer on the OATM segment will use WFW and access DOS- and 
Windows-based applications from the Pentium servers in IN- 15 8. The stacked ATM 
switches in IN-250 are connected to the 155 Mbps ATM switch in IN-158 by a 
multi-mode fiber cables. The connection supports speeds up to 155 Mbps between the 
stacked 25 Mbps switches in IN-250 and the 155 Mbps switch in IN-158. 

The instructor computer (N9) and six user computers (N10 through N15) 
keep their 9600 baud internal modem configuration. As with the current LAN, these 
modems will allow access to the Computer Center mainframe and the Sun Workstations. 
The modems will also allow access to the ATM network from remote locations. 

All 24 desktop ports of the stacked ATM switches are designated for use. 
Though the stacked switches are at maximum capacity (physically), a third ATM25 Switch 
(same vendor) can easily be added to the stacked switches to allow growth for 12 
additional computers. 
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Figure 5.5 IN-250 ATM LAN (OATM) 

d. A TM Segment 8 A TM (IN-1 58) 



IN-158 is the Software Metrics Lab. The redesigned integrated network in 
this dedicated lab comprises ATM and Token-Ring technology. Figure 5.6, on the 
following page, illustrates how the two networking technologies are integrated into one 
network. Regarding the ATM technology, a 155 Mbps ATM switch and an ATM LAN 
Bridge is used. The high-speed switch provides 155 Mbps connectivity to two Pentium 
Servers, the Stacked ATM25 Switches in IN-224 and IN-250, and the ATM LAN Bridge. 
The Pentium Servers, and the ATM LAN Bridge can be connected to the high-speed 
switch using either multi-mode fiber, STP, or Category 5 UTP cable. Vendors claim the 
Category 5 UTP cable supports 155 Mbps throughput rates. However, very few network 
administrators used this type of cable when upgrading to 155 Mbps ATM LANs. To 
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reduce risks of implementing new technology, Category 5 UTP should not be considered 
as an alternative. 




The ATM LAN Bridge provides connectivity to the ATM, Token-Ring, 
and Ethernet segments of the integrated network. This connectivity will allow the 
computers in the various segments to communicate and share resources though they may 
use different networking protocols. 

The Pentium servers (PN3 and PN6) will continue providing DOS- and 
Windows-based application services to users in IN-250. These servers will also continue 
running WFW. As additional pentium servers are added to the network, they should be 
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connected to the high-speed switch on Segment 8ATM. This will provide faster response 
time to the users. 

The 486 server (TN4) and the five Token-Ring computer will remain on 
Segment 8TR. One MAU is adequate to provide connection to the six computers. One 
port on the MAU will be used to link Segment 8TR to the ATM LAN Bridge. Server 
TN4 can continue providing DOS- and Windows-based application services and print 
services to user computers in IN-158. However, as faster servers are connected to the 
ATM155 switches, the applications and print services can be transferred to the faster 
servers, thus providing faster and better services to Software Metrics Lab users. 

The AppleTalk LAN and the PCLAN were not included in the integrated 
network in IN-158. Because the AppleTalk LAN and the PCLAN are proprietary and are 
in compliance with the IEEE 802 standards, very few vendors are producing products that 
are interoperable with these LAN protocols. As a result, I recommend that these LANs 
remain separate, and not be incorporated in the integrated network. If the LANs were 
included, the integrated network may become proprietary itself. 

e. Hardware Requirement 

Based on the physical design of the SM Lab ATM LAN, the hardware 
requirements to implement the LAN are provided in the table on the following page. The 
table provides the items, quantity, and special comments. 

As mentioned in the previous sub-section, UTP, STP, or Type 1 cabling, or 
a combination of these cable types can be used to connect the computers to the switches. 
However, for consistency and a more homogeneous network, it is better to use one type 
of cabling, either UTP or STP, to provide connectivity to each computer (server, 
instructor and user computers) connected to the ATM25 switches. Multi-mode fiber, or 
STP should be used for ATM25 Switch - ATM155 Switch, ATM155 Switch - ATM LAN 
Bridge, and ATM155 - Pentium Server links. Fiber and STP support the 155 Mbps 
throughput rate better than UTP. 
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Type 1 cabling is a possible option, particularly since this type of cable is 
currently in place, but few vendors are manufacturing NICs which are compatible with this 
cable (DB-9 connector). Also, additional Type 1 cable and connectors are required to 
extend the cable runs from each computer to the centralized switches (stacked). 



Item 


Qty 


Comments 


ATM155 Switch 


1 




12 Port ATM25 Switch 


4 


Most ATM25 Switches are configured with 12 ports. 
If an ATM25 Switch is configured with 16 ports, 
four switches are still needed. 


ATM LAN Bridge 


1 


Should support Token-Ring and Ethernet 
Connections 


Stacking Bus Option 


2 


For Switches in IN-224 and IN-250. 


155 Mbps Line Interface Cards 


9 


6 for ATM155 Switch. 

2 - one each for the ATM25 Switch 
1 for the ATM LAN Bridge 


25.6 Mbps Line Interface Cards 


0 


Typically, the ATM25 Switches require no Line 
Interface Cards for connection to computers. 
Instead, these switches are shipped with RJ-45 ports 
which are ready for connectivity. However, if there 
are requirements for specific configurations (certain 
cable or connectors), the ATM25 Switch may require 






41 Line Interface Cards. 


25.6 Mbps Network Interface Card 


41 


For Computers designated for connection to the 
ATM25 Switches. 


UTP or STP Cabling 




If all cabling replaced. 


Type 1 (STP) Cabling 




If existing Type Cable is used. 


Coax 




Backbone Connectivity 


Multi-mode Fiber Cable 




Switch-Switch and Pentium Server - Switch Links 


Connectors 






UTP, STP, Type 1 






Coax 


2 


Backbone Connectivity 


Multi-mode Fiber 


12 


Switch-Switch , Pentium Server-Switch, and ATM 
LAN Bridge-Switch Links 



Table 5 . 1 ATM Hardware Requirements 



Regardless of the type of cabling that would be used to provide 
connectivity, the appropriate NICs must be installed in the each computer. ISA or EISA 
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NICs are necessary for the 486 DX 33 MHz computers. The Pentium computers can use 
PCI configured NICs. 

3. Software Configuration 

a. Server and User Computer Configuration 

In order for ATM technology to function properly with any network, some 
form of change in the software configuration must occur in network servers and the user 
computers. Generally, these changes may encompass the replacement, upgrade, or 
modification of current network drivers (Token-Ring, Ethernet, etc.). These drivers are 
loaded into memory during the boot process to establish a logical connection between the 
computer and the entire system. The CONFIG.SYS file in the user and instructor 
computers contains the drivers. The servers also have a special file that is executed every 
time they are booted to create a network environment (Token-Ring, Ethernet, etc.) after 
loading appropriate network drivers into memory. 

The NIC drivers for the PCs and the servers must be compatible with the 
network operating system (NOS). This is also true with ATM network drivers. Many 
vendors are currently manufacturing ATM NIC drivers that function with WFW, 
Windows NT, and Netware. In some cases, the ATM drivers will not be compatible with 
all three. Therefore, if an office has a network which has all three of the these networks, 
different NICs from different vendors may be required. If so, this may lead to 
compatibility problems between the cards and the ATM switches if the vendors do not 
adhere to the ATM Forum standards. 

b. Switch Configuration 

Not only must appropriate network drivers be used to ensure a functioning 
ATM network; the ATM switches must also be configured properly. The switches must 
be configured to run as an IP network or a network using LAN Emulation. In the case of 
the SM Lab LAN, LAN Emulation should be used. The LAN Emulation protocol defines 
the mechanisms to emulate either an IEEE 802.3 Ethernet or an 802.5 Token-Ring LAN. 
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As discussed in Chapter II, the LANE protocol defines the operation of a 
single emulated system LAN (ELAN). Multiple ELANs may coexist simultaneously on a 
single ATM network since ATM connections do not collide. A single ELAN emulates 
either Ethernet or Token-Ring and must consist of LECs, a LES, BUS, and LECS. 
Chapter II, Section C.3 provided a detail description and function of these components. 

Based on the configuration of the SM Department Lab Network when this 
thesis was written, and the proposed design of the SM Department Lab Integrated 
Network, four ELANs are recommended. The former OTR Segment, the new OATM 
Segment, encompasses ELAN#1. ELAN#2 (IN-224) comprises of the smaller 4TR 
Segment, and the computers that are upgraded to ATM (Segment 4ATM). The Ethernet 
LAN (4EN) in IN-224 is ELAN#3. This LAN will remain intact and be connected to the 
ATM LAN Bridge. ELAN#4 includes a smaller 8TR Segment of the Token-Ring 
Network. The Pentium Servers will be a member of each ELAN because they provide 
application services to each ELAN. The ATM switches in the various ELANs will 
function as the LES(s), BUS(s), and LECS(s). Figure 5.7, on the next page, shows an 
illustration of the ELANs. 

Not only must the ATM Switches support LAN Emulation, the ATM LAN 
Bridge must also support LAN Emulation. Without this capability, the bridge will be 
unable to forward information to the correct ELAN or user. 

Appendix B provides information on LAN Emulation products (Hold, D. 

F„ 1995, p.l). 
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Figure 5.7 Systems Management Emulated LANs 



c. Virtual Connectivity 

Chapter II also discussed PVC (Permanent Virtual Circuit) and Switched 
Virtual Circuit (SVC) connections. PVCs are permanent or dedicated connections. 
Whereas, SVCs are established for information transmissions and tomdown after all 
information has reached the receiving end. 

In the case of the Systems Management Lab ATM LAN, PVCs should be 
used for connectivity to and from the servers and switch-to-switch connectivity. The PVC 
(full-duplex) throughput should be 25.6 Mbps and 155 Mbps, each way, for server and 
switch-to-switch connectivity, respectively. The Pentium Servers connected to the 
ATM155 Switch should have 155 Mbps connections. The other servers should have 25.6 
Mbps connections. SVCs should be used for user and instructor computers. Figure 5.8 
illustrates the proposed virtual connectivity for the ATM LAN. 
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By establishing PyCs for the servers and switch-to-switch connections, and 
SVCs for user and instructor computers, minimum dedicated virtual connections would be 
used. This reduces inefficient use of bandwidth. If PVCs were used for the user and 
instructor computers, each PVC would have to be from the port servicing the computer to 
the port servicing the server. If the computer communicates to more than one server, then 
additional PVCs are required. As one can see, if PVCs were used, network management 
would be drastically increased. Also, more time is required to establish and maintain 
PVCs. 



d. Software Requirement 

Table 5.2 provides a list of essential software to ensure the proper 
functioning of the SM Lab ATM LAN. Each room should require ATM Switching 
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software to operate their appropriate segment of the LAN. The software should have 
drivers for Novell Netware NOS, WFW, and Windows NT. These drivers will allow the 
SM Department Lab Network to operate in an ATM environment as it migrates from a PC 
LAN network to a WFW/Windows NT network. 

The stacked switches in IN-224 and IN-250 should each require the 
Stacking Bus Module. The Module should allow the use of one copy of ATM Switching 
software instead of the actual number of "stacked" switches. 

The ATM Switching software drivers for the ATM25 and ATM155 
Switches should be compatible with the 25.6 Mbps NICs, the 155 Mbps Line Interface 
Cards. To ensure switch, driver, and card compatibility, the same vendors should produce 
the 25.6 Mbps NICs, the 155 Mbps Line Interface Cards, switches, and ATM LAN 
Bridge. If the same vendor does not produce these items, the group of vendors that 
manufactures the software and drivers must adhere to ATM standards to ensure 
compatibility and interoperability. 



Item 


Qty 


Comments 


ATM Switch Software 




Operating System for the Switches must have drivers 
for Netware, Windows for Workgroup, and Windows 
NT. The Switch Software must support LAN 
Emulation. This requirement is also applicable to 
all Drivers. 


Stacking Bus Module 


2 


For Switches in IN-224 and IN-250. 


25.6 Mbps NIC Drivers 


41 


For Switches. 


155 Mbps Line Interface Drivers 


7 


Switch-Switch Connectivity. 


ATM LAN Bridge Software 




Must be compatible with the switch software. 


LAN Emulation Software 




All switches, the ATM LAN Bridge, and drivers 
must have LAN Emulation capability. 



Table 5.2 ATM Software Requirements 



The LAN Emulation software and drivers are of utmost importance to 
ensure that the applications on the current SM Department Lab Network are functional in 
an ATM environment. As discussed in Chapter IV, Token-Ring and Ethernet are the 
primary network technologies in the SM Department Lab Network. The applications are 
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designed to run of over these shared medium networks. Standard software interfaces or 
drivers such as Novell's ODI or Microsoft's NDIS interface support these applications. 

ODI and NDIS provide network transport services to the application 
software that operates in both the server and the client workstation, and these services 
reflect the underlying nature of the LAN technology. Today's Token-Ring and Ethernet 
LANs provide connectionless "best effort" delivery of variable length packets which are 
addressed to a specific physical interface(s). These LAN technologies also support 
broadcast and multicast packet delivery, whereby a packet with a certain address will be 
delivered to all, or a subset of, the workstations on the network. 

The higher layer of the communications software in LAN end stations, 
including the client "shell" and the server operating system, have evolved around this 
functionality. (Taylor, Martin. 1995, p.9) 

ATM networks operate differently than today's traditional networks. ATM 
is connection-oriented, in which a connection is established before any information is 
forwarded to the destination. Also, data is fixed length, and is sent to the appropriate 
destination(s) by the use of virtual channel identifiers instead of addresses to a physical 
interface card. Last, but not least, ATM does not provide a true equivalent of broadcast 
and multicast services offered in today's LANs. 

LAN Emulation is the "solution" to the problem of running existing LAN 
applications over an ATM network. This procedure defines a "LAN Emulation Client" 
(LEC) process to function in each station, which adapts the connection-oriented cell 
transport service provided by ATM to the connectionless packet transport service 
demanded by the applications. Figure 5.9 shows how LAN applications run on an ATM 
network. (Taylor, Martin. 1995, p.9) 
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LAN Emulation Client Process 



LAN Application 



E 



Send Data 




Receive Data 


Destination Address 




Destination Address 


Source Address 




Source Address 


Data 




Data 



I 



I 



ATM Network 



Figure 5.9 LAN Emulation Client Process 
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VCI Data 
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As depicted in the above figure, the LEC process handles the transmission 
and receipt of LAN packets from the ATM network, as follows (Taylor, Martin. 1995, 



p.9-10): 
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♦ When a client request to transmit a packet, the LEC process receives packet's 
LAN destination address and determines the ATM station address. If no 
virtual channel connection is set to this address, the LEC request that the ATM 
switch establish a connection. Once the connection is made, the LAN packet is 
segmented into ATM cells and transmitted over the connection. 

♦ If a client or server request to transmit a broadcast packet, the LEC segments 
the packet into cells and transmit the cells to the Broadcast and Unknown 
Server (BUS). The BUS maintains a list of all the stations on the ATM LAN 
and sends the cells to all stations on the list. As a result, the appropriate 
stations receive the broadcast packet. 

♦ When an end station or server receives a stream of ATM cells, the LEC 
re-assembles the cells, re-creates the original LAN packet, and forwards the 
packet to the application. 

The LEC process uses one of the standard network software interfaces 
(ODI or NDIS) to communicate with the end station's or server's application software. In 
actuality, the LEC emulates a standard ODI or NDIS network adapter card driver, tricking 
the end station software into believing that it is communicating with a Token-Ring or an 
Ethernet adapter. Manufacturers incorporate the LEC process into the driver software 
that shipped with the ATM adapter. As a result, it is a simple process to install an ATM 
adapter complete with LAN Emulation in a server or client software environment. 
(Taylor, Martin. 1995, p.9) 

4. LAN Management 

Every network, regardless of size or type, requires network management. This 
will be particularly true for the proposed ATM LAN. However, to properly maintain the 
ATM LAN, personnel, personnel training, documentation, and maintenance tool are 
required. The subsequent sub-subsections address these requirements. 
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Personnel and Training Requirement 



Two or more people may be required to maintain the proposed integrated 
network. These people will be responsible for the upkeep (adding, deleting, and 
modifying virtual and physical connections) of the network. They will also perform 
upgrades to the ATM Switch software as new ATM standards are released, and upgrade 
user, instructor, and server computers. 

The current LAN administrator is very familiar with existing LAN 
technology. However, he will require ATM training, and possibly training in the 
installation of fiber, and UTP, or STP cable. 

b. Documentation 

Documentation is of utmost importance when implementing the design of 
the ATM network. As with the Token-Ring and Ethernet networks, documentation of 
physical connections is necessary. However, documentation of logical links is very critical 
for the integrated network. Though all physical connections may be up, information will 
not reached the proper destination unless the correct logical connection is established. If 
information is not reaching the right destination, and all physical connections are 
established, the administrator's next step is to ensure that the switches establish the proper 
logical connection. This is done by verifying the virtual connection. This task may be 
very difficult to perform without proper physical and logical documentation, particularly in 
a large network. 



c. Maintenance Tools 

Graphics user interface (GUI) maintenance tools will greatly assist the 
LAN administrator in maintaining the ATM network. However, these tools can be very 
expensive. A small ATM network may not require a GUI maintenance tool. The text 
editor should be sufficient for the small network. Because the SM Lab Integrated 
Network will consist of 10 servers, 43 clients, and backbone connectivity, a GUI 
maintenance tool may be necessary. This tool must be compatible with the ATM 
switches. 



86 



Most ATM GUI maintenance tools nan on UNIX platforms. However, 
manufacturers have begun producing tools that can run on a Windows NT platform. This 
is a great stride forward for ATM25 networks, since most PC networks are Windows-, 
Windows NT-, or DOS-based. The Windows NT GUI tool would greatly assist the LAN 
administrator in maintaining the proposed integrated network. 

D. CHAPTER SUMMARY 

This chapter discussed the design of an integrated network comprised of ATM, 
Token-Ring, and Ethernet technologies. However, before covering the design of the 
proposed integrated network, the chapter covered the ATM network installed for the 
Supercomputing 1995 conference in San Diego, CA. The Supercomputing 1995 
conference network provided me a better understanding of how an ATM network is 
designed and implemented, both physically and logically. As a result, this knowledge 
greatly assisted me in the design of the proposed SM Lab Integrated Network. 

Several key areas were covered the physical and logical design of the 
recommended network. One in particular was the use of one vendor for the integrated 
network. To ensure compatibility of the network, one vendor should manufacture the 
switches, an ATM LAN Bridge, LINF cards, and NICs. The vendor should also be an 
active member of the ATM Forum, adhere to ATM standards, and understand ATM 
technology and its evolution. 

Not only are the switches, ATM LAN Bridge, LINF cards, and the NICs crucial in 
the physical implementation of an ATM network, but the cabling plant is also critical. 
Over 90% of the SM lab network cabling plant is Type 1 (STP). Though ATM runs over 
Type 1 cable, very few vendors produce cards which are compatible with Type 1 cable. 
Mainly STP, UTP, coax, and fiber are the forms on which cable vendors are focusing. 

To ensure compatibility and not be left with few vendors to procure ATM 
hardware from, UTP and fiber are the recommended choices of cable for the Systems 
Management Lab Integrated Network. UTP should be used to connect the user and 
instructor computers and the servers to the ATM switches. Multi-mode fiber should be 
used for switch-switch, ATM LAN Bridge-switch, and Pentium Server-switch 
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connectivity. The fiber is recommended for these connections because of 155 Mbps 
throughput rate, distance (switch-switch connectivity), and the possibility of noise 
interference. 

The ATM switches recommended for the lab network are based on the ATM25 
and ATM155 technology. This technology is suitable for the lab network because 
ATM25 was designed for PC desktop networks. The ATM25 switches should comply 
with ATM standards, particularly LAN emulation and UNI 3.0 standards. LAN emulation 
will allow the ATM network function like a Token-Ring or Ethernet network. The UNI 
3.0 standard allows the use of SVCs and PVCs. 

The ATM155 Switch will provide high-speed data rates between the switches, and 
to the ATM LAN Bridge and Pentium Servers. The ATM155 Switch must also comply 
with ATM standards.. 

The switch software must not only address these standards, but it must also use 
drivers for Novell Netware, WFW, and Windows NT. The LINF cards and NICs for the 
computers must also use compatible drivers. The drivers for the NICs must be loaded on 
each computer that will be connected to the ATM switches 

If all the hardware (ATM switches, cabling, LINF cards, NICs, and computers) are 
properly connected, the ATM network is still not guaranteed to function properly. Both 
physical and logical connectivity must be established. Logical paths (virtual circuits) must 
be configured after physical connectivity has been established. 

Other areas of concerns are personnel, training, documentation and maintenance. 
These areas, and the proper physical and logical connectivity of the ATM network are a 
must to efficiently and effectively run the integrated network. 
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VL MIGRATION OF SM DEPARTMENT LAB LAN TO AN ATM LAN 



A. PURPOSE OF CHAPTER 

The purpose of this chapter is to discuss a migration strategy to upgrade the 
existing SM Department Networks Lab from Token-Ring and Ethernet technologies to an 
integrated network encompassing not only ATM technology, but also Token-Ring and 
Ethernet technologies. Because of the higher throughput rates ATM offers, and the 
greater data rates users will expect once a computer is upgraded to ATM, this chapter will 
also discuss the speed limitations of existing computers when they are connected to an 
ATM switch. 

B. INTEGRATED LAN MIGRATION STRATEGY 

1. Overview 

The redesigned SM Department Networks Lab LAN discussed in the previous 
chapter should not be implemented in one phase. A one-phase implementation will 
produce an extended period of downtime, administrative and maintenance training, and a 
tremendous technology risk and monetary investment. Instead, the migration must be 
done in phases to minimize network disruption, maintenance headaches, technology risks, 
and costs. Each phase should leverage as much of the existing technology (hardware and 
software configuration) as possible, and preserve the network infrastructure (Lindsay, S., 
Rosenblum, D. and Walleigh, W., 1995). Other factors to consider when migrating to a 
high-speed network include: 

♦ Existing network technologies; 

♦ Budget; 

♦ Where network bottlenecks occur; 

♦ Type of cabling available; 
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♦ Types of future application for the LAN; 

♦ Timeframe considerations (Carr, I, 1995, p. 60). 

There are many high-speed network technologies available in the marketplace 
which may be used to upgrade the SM Department Networks Lab LAN. These 
technologies include Fast Ethernet (lOObaseT), lOOVG-AnyLAN, FDDI, and ATM. 
However, this thesis focuses on designing an ATM LAN that would possibly be an 
upgrade to the current LAN. Therefore, I will only discuss a possible migration strategy 
using ATM technology. 

The availability of funds will determine how quickly a high-speed networking 
technology will be phased into an existing network. Even if a vast amount of funds were 
available, bottleneck areas should be considered as the first area to migrate to high-speed 
pipes. This approach will minimize disruption to the network, the procurement of new 
hardware and software, and improve overall performance of the network. 

The migration strategy should also use as much of the existing cabling plant as 
possible to minimize cabling cost (material and installation). The other two factors, types 
of future applications and timeframe considerations, will also determine how quickly or 
slowly one would implement a high-speed network technology. In the case of the SM 
Department Networks Lab LAN, these two factors can be used to extend the migration to 
phase in ATM technology. The current network is only used for data (text) transfer and 
not to transmit or receive voice, video, and images. 

To devise a migration strategy for the SM Department Networks Lab, budgetary, 
bottleneck areas, and cabling plant availability and compatibility are primary concerns. 
These concerns are used in creating a six phase approach to provide ATM services to the 
desktop. These phases are discussed in the subsequent subsections. The network 
administrator can combine several of the phases if additional funds are available or time 
becomes a critical factor. 
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2. Phase I: Upgrade Pentium Servers (IN-158) to ATM 

The first phase of the SM Department ATM LAN evolution is the conversion of 
the Pentium Servers (PN3 and PN6) in IN-158 from 16 Mbps Token-Ring to 155 Mbps 
ATM. These servers are converted first because excess traffic on a Token-Ring LAN 
creates throughput problems which causes the servers to respond sluggishly or 
inconsistently to application requests. This may cause sessions to die while waiting for 
acknowledgments from a far end of a connection. As a result, user productivity degrades. 

The converted servers are connected to a 155 Mbps high-speed ATM Switch. 
This switch will be connected to an ATM LAN Bridge. The primary purpose of the 
bridge is to provide connectivity to the ATM Switch and the existing Token-Ring 
network. Therefore, no changes are required to the existing Token-Ring infrastructure, 
and users will have the ability to access the DOS- and Windows-based applications on the 
Pentium Servers using ATM technology. Also, backbone connectivity remains intact. 
Figure 6. 1 illustrates the Phase I implementation. 
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3. Phase II: Integrate the Ethernet LAN (4EN) into the Network 

As shown in Figure 6.2, next page, the only difference between Phase I and Phase 
II is the connection of Segment 4EN (Ethernet) to the ATM LAN Bridge. This addition 
will require a coaxial cable run from IN-224 to IN- 158 to physically connect the Repeater 
to the bridge. Both the repeater and the bridge must be compatible in order for the 
connect to function properly. 

While running the coaxial cable from IN-224 to IN- 15 8, the cable installer may 
also want to run a multi-mode fiber cable. The multi-mode fiber will be required to 
connect an ATM25 switch to the ATM155 switch in IN-158 during Phase IV. 

One key advantage about this phase is that Ethernet users will have the ability to 
access applications on the various servers on the network. Also, in the WFW 
environment, the 4EN users will have peer-to-peer, and peer-to-server capabilities. These 
new capabilities are much more than the current functionality of the 4EN users. The 4EN 
users can only perform TCP/IP functions, via the Ethernet campus backbone connection, 
with the Token-Ring users. 

Regarding the Ethernet campus backbone connection, this connection will remain 
in place during this phase. 
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SM Department ATM LAN Evolution, Phase II 



(8ATM) 




Figure 6.2 SM Department ATM LAN Evolution, Phase II 

4. Phase ID: Disable 4EN Backbone Connection 

In Phase ID, the Ethernet campus backbone connection is disabled. However, the 
AUI cable run will remain in place. By leaving the cable in place, this links can be used as 
a secondary or backup backbone connection should the Token-Ring backbone connection 
becomes inactive. 

The Ethernet users will still have access to the campus backbone via the ATM 
LAN Bridge and Segment 4TR (Token-Ring). With this access, the Ethernet users keep 
their internet capabilities. 

Figure 6.3 shows the disabling of the Ethernet campus backbone connection. 
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5. Phase IV: Upgrade Four IN-224 Computers to ATM 

Phase IV involves migrating computers from Token-Ring to ATM. This stage will 
require the installation of multi-mode fiber cable from IN-224 to IN-158 to connect a 25.6 
Mbps ATM Switch to the high-speed 155 Mbps ATM Switch. The connection will 
require two 155 Mbps Line Interface Cards, one for each switch, and the appropriate 
connectors. 

After connectivity between the switches have been established, and the switches 
have been configured, computers can be connected to the ATM25 Switch. ATM NICs, 
and STP or UTP cable are necessary to make these connections. The ATM25 Switch, 
NICs, and cable must be compatible to obtain a connection. 

As shown in Figure 6.4, the 4ATM segment co-exists with all three Token-Ring 
segments and 4EN. The users in 4ATM will be able to communicate with the servers and 
other users of the integrated network. 
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6. Phase V: Upgrade Four IN-250 Computers to ATM 

During Phase V, several computers in IN-250 will be converted from Token-Ring 
to ATM. This stage will require the installation of multi-mode fiber cable from IN-250 to 
IN-158 to connect a 25.6 Mbps ATM Switch to the high-speed 155 Mbps ATM Switch. 
Like the IN-224 and IN-250 ATM link, this connection will require two 155 Mbps Line 
Interface Cards, one for each switch, and the appropriate connectors. The same 
procedures done to connect the computers in IN-224 to that ATM25 Switch is required to 
connect the computers in IN-250 to an ATM25 Switch. 

Figure 6.5 illustrates the progression in the integrated network, with the addition 
of the ATM25 Switch in IN-250. 
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7. Phase VI: Convert All IN-250 Computers and 13 IN-224 Computers 

Phase VI is the final stage in evolving the SM Department Lab LAN from 
Token-Ring and Ethernet technologies to an integrated network comprised of ATM, 
Token-Ring, and Ethernet technologies. This phase entails upgrading all but three 
Token-Ring configured computers in IN-224 to ATM. All remaining Token-Ring 
configured computers in DSf-250 will be upgraded to ATM. An additional switch is 
necessary for both rooms to accommodate the newly converted computers. These 
switches will be stacked on top of the original ATM25 Switches in each room using the 
Stacking Bus Option. The newly reconfigured stacked switches in IN-224 and IN-250 
increase the capacity of each room to support 24 computers. 
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Only 17 computers in IN-224 will be upgraded to ATM, leaving three Token-Ring 
configured computers on Segment 4TR. Twenty-four of the 25 computers in IN-250 will 
be converted to ATM. The remaining computer in IN-250 can either remain on Segment 
OTR. However, since the Pentium Servers in IN- 158 will become the application servers 
for IN-250, fewer servers will be required in IN-250. As a result, all user computers, 
including the instructor computer, can be converted to ATM. 

Even though the stacked switches in IN-250 is at maximum capacity, a third 
switch can easily be added to the stack should the number of ATM computers becomes 
25 or greater. 

Figure 6.6, on the next page, shows the implementation of Phase VI. This final 
implementation consists of the following: 

♦ Segment OATM - Stacked ATM25 switches and 24 ATM configured 
computers; 

♦ Segment 4ATM - Stacked ATM25 switches and 17 ATM configured 
computers; 

♦ Segment 8 ATM - an ATM155 Switch, ATM LAN Bridge, and two Pentium 
Servers. Additional high powered servers can be added the ATM155 Switch; 

♦ Segment 4TR - a MAU, three computers, backbone connection, and an ATM 
LAN Bridge connection; 

♦ Segment 8TR - a MAU, 486 Server, five clients, and an ATM LAN Bridge 
connection; 

♦ Segment 4EN - Ethernet Repeater, five computers, a disabled backbone 
connection, and an ATM LAN Bridge connection. 
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SM Department ATM LAN Evolution, Phase VI 
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Figure 6.6 SM Department ATM LAN Evolution, Phase VI 



C. THROUGHPUT LIMITATIONS 

Though ATM is a "relative" new networking technology, it is growing in 
popularity and is being adapted by many companies and institutions. These organizations 
have realized the benefits ATM offers, such as a vast room for growth in bandwidth. 
Numerous other benefits are discussed in Chapter II. 

Even with the on-going evolution of ATM standards, products (ATM switches, 
line interface cards, NICs, etc.) are being manufactured. Most of the products are in 
compliance with the existing ATM standards. As a result, these products can be procured 
and configured to form a fully functioning ATM network. The network can serve users 
within a single building or campus, or even users thousands of miles apart. The network 
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can support speeds ranging from 25.6 Mbps to 2.4 Gbps. The high throughput would 
support ATM backbones. 

Though ATM supports these high rates of throughput, an Information Technology 
Manager must ask himself the following technical questions: 

♦ Can the ATM network support all popular PC buses (ISA, EISA, PCI, 
NuBus), device drivers for my operating system (WFW, Windows NT, Novell 
Netware)? 

♦ Does the ATM network emulate LANs for both ATM adapters and 
internetworking devices. 

♦ Can my existing PCs or workstations handle ATM speeds? 

Chapters II and V address the first two questions. Therefore, the next paragraphs 
will focus on throughput. 

Communications Week tested four ATM switches during the summer of 1995. 
The tests focused on the switches' viability as desktop network interfaces. The switches 
included Fore Systems Inc.'s ForeRunner ASX-200BX, Newbridge Networks Inc.'s Vivid 
ATM Workgroup Switch, 3Com Corp's Cellplex 7000, and UB Networks Inc.'s 
GeoSwitch/155. Though these switches provided 155 Mbps bandwidth, the throughput 
tests performed by Communications Week illustrate the bottleneck of the network when 
using ATM technology. (Mier, E. E., Smithers, R. J., Jr., 1995, p. 129) 

Communications Week implemented single- ATM- switch LANs, connected 
Pentium-based PC workstations to the switches using 155 Mbps multi-mode fiber 
adapters, and transferred real data traffic over TCP/IP. Each Pentium computer had 64 
Mbytes of RAM, and a clock speed of 90 MHz. Half of the PCs ran Window NT Server 
3.51, and the remaining half ran Windows NT Workstation 3.51. 

Communications Week tested the throughput speeds of the 155 Mbps 
(bi-directional) ATM network and an Ethernet running at 10 Mbps. The technicians 
determined that the effective user data throughput over Ethernet, within a Windows NT 
Workstation and a Windows NT Server as the only active nodes, was 4 Mbps. The file 
size was 323 megabytes. 
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The same file was transferred over the ATM PVC. The data transferred at an 
effective rate of 13 Mbps. As one can see, this is nowhere near 155 Mbps. Disk I/O 
limited the transfer rate to 13 Mbps. 

To perform the file transfer without conducting disk I/O functions, the technicians 
performed a cache memory-to-cache memory transfer of a 50 megabyte file (the cache 
could not hold the 323 megabyte file). The effective transfer of the 50 megabyte file was 
30 Mbps, also much smaller than the 155 Mbps. 

These throughput rates would have been much smaller had Communications Week 
used PCs with configurations identical to the PCs in the SM Department computer labs. 
Even ATM 25 Mbps switches would not have been used to their fullest potential. 

Though ATM 25 Mbps switches exceed the throughput limitations of the SM 
Department Computer Lab LAN, the switches would allow room for growth and 
expansion of the network. As newer and more powerful PCs replace the existing 486 
PCs, the overall throughput speed would increase. 

D. CHAPTER SUMMARY 

This chapter discussed the proposed implementation strategy to incorporate ATM 
technology into the SM Department Lab LAN. The strategy pursued a course which 
would minimize disruption, downtime, maintenance, and training. In the six phases, 
existing hardware and software are used to the fullest extent to minimize costs and risks. 

Because of the redesigned and proposed implementation of the LAN, Token-Ring, 
and Ethernet became an integral part of the ATM LAN. This is accomplished through 
LAN Emulation. By having all three technologies in one integrated network, the students 
and staff will gain tremendous experience on these three networking technologies and how 
they function in one integrated environment. 

One key advantage of the integrated network is that users will retain the ability to 
use existing applications through the use of LAN Emulation. The users will also have 
greater throughput with room for bandwidth growth as applications become more 
powerful, and demand additional bandwidth. 
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Lastly, the ATM segments will have the ability to support data, voice, and video 
transmission. Though the SM Department Lab users currently transmit text, future 
information technology procurements may include more powerful servers and clients. 
These computers may have multi-media capabilities which could possibly lead to the 
sharing of multi-media resources across the integrated network. 
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vn. CONCLUSION 



User demand for additional bandwidth will continue to increase. In many cases, 
this demand will grow at a rate faster than workstation processing power. Since the SM 
Department is upgrading its computer lab network to WFW, and eventually to Windows 
NT, more powerful applications will be able to run on the network. These applications 
will require faster servers and clients, and additional bandwidth. Even if the servers and 
clients are replaced with much faster computers, the current Token-Ring and Ethernet 
technologies will be the limiting factor. These technologies only support 16 and 10 Mbps 
data rates, respectively, and are not capable of supporting the transmission of voice, data, 
images, and video. 

ATM provides the throughput rates (25.6, 155, and 622 Mbps, and higher) and the 
capability to carry voice, data, images, and video. However, this technology comes with a 
high price tag and risks. One would not want to replace his existing shared-medium 
network with an ATM network in one phase. Instead, ATM technology should be phased 
into the existing network. This approach reduces risks, and maximizes the use of existing 
hardware and software. The migration or evolution strategy also allows time for the ATM 
standards to mature and to be implemented by manufactures. Cost also plays a critical 
role in the evolution strategy. It is expected that ATM prices will continue to decrease 
and become more competitive with other switching technologies such as Switch Ethernet 
and Switch Token-Ring. 

Should the SM Department decide to upgrade the computer lab network to ATM, 
and elect to use the proposed migration strategy or even a different evolutionary plan, the 
manufacturers that provide the ATM technology will play a crucial role during and 
following the implementation. The manufacturers should be a member of the ATM 
Forum, adhere to ATM standards, and understand the ATM technology and its evolution. 

If the manufacturers meet these criteria, the ATM products will be interoperable 
and compatible with other vendors ATM products; most of all, the products will function 
with existing LAN applications. The ATM equipment will also have a longer technology 



103 



life cycle (i.e., if a new ATM standard is released, the items 
standard, and not become obsolescence). 



easily adapt the new 
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APPENDIX A. ATM FORUM CURRENT WORK ITEMS 



ATM FORUM CURRENT WORK ITEMS AS OF DECEMBER 1995 
The ATM Forum Technical Committee 



Technical Working 


Principal Work Effort 


Status 


Approval 


Group 






Forecast 


Lan Emulation Chairman; 


LANE V2.0 LUN1 Interface 


Work In Progress 


10/96 


Kieth McCloghrie 


LANE V2.0 Server-to-server Interface 


Work In Progress 


10/96 




LANE 1.0 Addendium, af-lane-0050.000 


Final Ballot 


2/96 




LANE Service MIBs 


Straw Ballot 


4/96 


MPOA Chair: 
George Swallow 


Specific Development 


Work In Progress 


2/97 


Traffic Mgmt Chair: 


Traffic Management 4.0 


Straw Ballot 


2/96 


Natalie Giroux 


Service Architecture 
ABR (Available Bit Rate) 
QoS (Quality of Service) 






Service Aspects and 


Native ATM Services: Semantic Description 


Final Ballot 


2/96 


Application Chair: 


Audio/Visual Multimedia Services VLO 


Final Ballot 


2/96 


Dean Skidmore 


FUNI (Frame-based User-to-Network Interface) 


Approved 


10/95 




Circuit Emulation 


Approved 


10/95 




Directory Services 


Work In Progress 






Voice & Telephony over ATM 


Work In Progress 


10/96 


P-NNI Chair: 


P-NNI VLO (Private N etwork-to-N etwork Interface) 


Straw Ballot 


4/96 


Mike Goguen 


MIB contains P-NNI Signaling and Routing Protocols 






Physical Layer Chair: 


E-l 


Straw Ballot 


4/96 


Rick Townsend 


25.6 Mbps 


Approved 


10/95 




155 UTP-3 


Final Ballot 


2/96 




622 Optical 


Final Ballot 


2/96 




ATM Inverse Mux 


Work In Progress 






Utopia Level 2 


Straw Ballot 


2/96 




Wire (PMD to TC layers) 


Work In Progress 






E3UNI 


Approved 


10/95 




DS3 Physical Layer Interface Spec 


Final Ballot 


2/96 




120 Ohm Addendum to ATM PMD 


Straw Ballot 


4/96 




Interface Spec for 155 Mbps over TP, af-phy-0053.000 


Straw Ballot 


4/96 


Signaling Chair: 
Tom Helstem 


UNI Signaling 4.0 


Straw Ballot 


6/96 


B-ICl Chair: 

I Richard Breault 


B-1CI 2.0 


Straw Ballot 


4/96 


Network Management 


M4 Public Network view 


Final Ballot 


2/96 


Chair: Roger Kosak 


M4 SNMP MIB Network Element 


Work In Progress 


4/96 




M3 (CNM) Update 


Work In Progress 


6/96 




M4 Public Network view SNMP & CMIP MIB 


Work In Progress 


6/96 




Power Management 


Work In Progress 


9/96 




M5 Carrier Interface 


Work In Progress 


9/96 
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Testing Chair: 


PICS for AAL (ITU spec) 


Final Ballot 


12/95 


Gregan Crawford 


PICS for Signaling (UNI V3.0) 


Tabled 






PICS for Signaling (UNI V3. 1) 


Work In Progress 






Conformance Abstract Test Suite for ATM layer (End Sys) 


Approved 


10/95 




Conformance Abstract Test Suite for the AAL5 Sub-Layer 


Final Ballot 


2/96 




Conformance Abstract Test Suite for SSCOP Sub-layer 


Work In Progress 






Conformance Abstract Test Suite for Signaling (UNI 3.1) - 


Work In Progress 






User Side 

Conformance Abstract Test Suiite for UNI 3. 1 at the ATM 


Approved 


12/95 




Layer for Intermediate Systems 
PICS for UTP-3 (52 Mbps) 16 CAP Physical Layer 


Final Ballot 


2/96 




PICS for the 25.6 Mbps over UTP-3 Physical Layer 


Final Ballot 


2/96 




Conformance Abstract Test Suite for the UNI 3.1 ATM Layer 


Straw Ballot 


4/96 




of End System 






RBB (Residential 
Broadband) 

Chair: Stanley Ool 


Requirements for Specification: RBB Specification 


Work In Progress 


12/96 


Security Chair: 
Mohammed Peyravian 


Security 1.0 


Work In Progress 


2/97 


Work in Progress: All work up to release of working documment for Straw Ballot 






Straw Ballot: Specification released for test vote with comments (some may require two rounds). 




Final Ballot: Final specification presented for vote or membership. 

Approval: Approval vote received 







112 




APPENDIX B. THE ATM REPORT GUIDE TO LANE PRODUCTS 



ATM Switches, Hubs, & Routers 


Company 


Product 


LAN Emulation 


IETF IP over ATM 


Agile 


ATMizer 125 ATM Switch 


ATMF LANE 1.0 


RFC 1483 


Alantec 


PowerCell 350 module for 
PowerHub 3000/5000 & 
PowerHub 3160 

Power Cell 700 
PowerCell 600 


FORE LANE 

ATMF LANE 1.0 -IQ 96 

ATMF LANE 1.0 - IQ 96 
ATMF LANE 1.0 - IQ 96 


RFC 1577 -IQ 96 
RFC 1577 -IQ 96 


ATM Inc. 


Virata Switch 


ATMF LANE 1.0 




Bay Networks 


EtherCell Switch 
LattisCell 

System 5 000 AH ATM Module 
Backbone Node Routers 
(BLN & BCN) 


ATMF LANE Client 
ATMF LANE 1.0 
AMTF LANE 1.0 
AMTF LANE 1.0 


RFC 1483 
RFC 1483 & 1577 


Cisco 


Cisco 7000 with AIP 
Cisco 4500/4700 with NPN 
Cisco IOS for ATM Software 
Cisco Catalyst 5000 


ATMF LANE 1.0 
ATMF LANE 1.0 
AMTF LANE 1.0 
AMTF LANE Clinet 


RFC 1483 & 1577 
RFC 1483 & 1577 
RFC 1483 & 1577 


3Com 


CELLplex 7000 & 7200 ATM 
Module 

LinkS witch 2700 


AMTF LANE 1.0 
AMTF LANE Client w/SVCs 




CrossComm 


XLT-F Edge Router 
AES ATM/Ethemet Edge 
Switch 


ATMF LANE Client 
AMTF LANE 1.0 Client 
IQ 96 


RFC 1483 & 1577 
RFC 1483 


Digital 


GigaS witch ATM 
DECNIS ATMcontroller 63 1 


AMTF LANE 1.0 


RFC 1483 & 1577 
RFC 1483 & 1577 


First Virtual 


Media Switch 


AMTF LANE 1.0 


RFC 1483 & 1577 


FORE 


ASX-1000 & ASX-200 WG* 
& ASX-200BX 


FORE LANE 0.4 
ATMF LANE 1.0 - IQ 96* 


RFC 1483 & 1577 


IBM 


8281 ATM LAN/Bridge 
8285 ATM Workgroup Switch 


IBM LANE 
AMTF 1.0 -IQ 96 


RFC 1483 & 1577 
RFC 1483 & 1577 


Madge 


Collage 250 - IQ 96 
Collage 280 


ATMF LANE 1.0 




Newbridge VIVID 


Vivid Switches & Bridges 


Newbridge MPOA 


RFC 1483 


NSC 


ERS 


ATMF LANE 1.0 




ODS 


Warrior Switch 
FORE Module 
AnyCel! ATM25 


ATMF LANE 1.0 
FORE LANE 
IBM LANE 


RFC 1483 & 1577 


UB Networks 


GeoSwitch/155 


ATMF LANE; Client & 
Server services 




Whitaker (Hughes LAN) 


Enterprise Hub 
Ethernet Switch with ATM 


ATMF LANE 1.0 
ATMF LANE 1.0 




Whitetree 


Whitetree WS3000 


ATMF LANE 1.0 




Xyplex 


520 ATM Edge Router Module 


ATMF LANE 1.0- 1Q96 


RFC 1483, 1577- IQ 96 
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Xylan 


OmniSwitch with OmniCell 
ATM Matrix - Ql 96 


ATMF LANE 1.0- IQ 96 


RFC 1483 & 1577 




7000 Series 


ATMF LANE 1.0 





ATM NICs 


Company 


Product 


LAN Emulation 


IETF IP over ATM 1 


Adaptac 


ATM 155 for SBus & PCI Bus 
ATM25 for PCI, SBus, Micro 
Channel 


ATMF LEC 


RFC 1577 


ATM Inc. 


Virata Link 


ATMF LANE 1.0 Client 




3Com 


ATMLink 155 Mbps for SBus 


AMTFLANE 


RFC 1577 


Digital 


ATMworks 750 & 350 for 
Turbo channel & PCI 


AMTF LANE Client 


RFC 1577 


Efficient Networks 


155 Mbps SBus, PCI, EISA 
100 Mbps SBus, EISA 
25 Mbps PCI -IQ 96 


ATMF LANE 1.0 


RFC 1577/1755 


First Virtual 


Media Adapter 25 Mbps 


AMTF LANE 1.0 Client 




FORE 


ATM NICs for Sbus, EISA, 
GIO, MCA, VME, NuBus, 
PCI, MAC-PCI 


FORE LANE 

ATMF LANE 1.0 -IQ 96 


RFC 1483/1577 - IQ 96 


IBM 


Turbo Ways 25/100/155 Mbps 
NICs for ISA, MCA 


IBM LANE 
AMTF 1.0 -IQ 96 




Interphase 


155 Mbps PCI, Sbus, EISA, 

VME, GIO, PMC 

100 Mbps SBus, EISA, VME 


ATMF LANE 


RFC 1577 (SVCs) 
RFC 1483 (PVCs) 


Madge 


Collage 25/155 Mbps NICs 
for PCI 


ATMF LANE 1.0 




Packet switch Tech. 


IAX-210 155 Mbps PCI NIC 




RFC 1577 


SysKonnect 


SK-NET 155 Mbps NICs 
for SBus, EISA, & PCI 




RFC 1577 


ZeitNet 


155 Mbps NICs for PCI, 
SBus, EISA, & OIO 


LANE Client, Server, & BUS 


RFC 1483 & 1577 



* - Fore ASX-200WG LANE server software supports diretly attached clients only. 
FORE will offer ATMF LANE 1.0 compliance on all products by 3/96. 

MPOA - Multiprotocol over ATM 

RFC 1483 - defines the encapsulation of IP datagrams directly in AAL5. 

RFC 1577 - is intended to make IP run over ATM as efficiently as possible. 
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